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PREFACE 



This publication describes the 
Conversational Monitor System (CMS) EXEC 
facilities available to VM/370 users. It 
contains both introductory and reference 
information about the EXEC facilities for 
any VM/370 users who want to use them. In 
addition, it contains a section that 
illustrates many useful techniques of EXEC 
procedure design and implementation. 



To use this book effectively, you should 
have a general understanding of basic 
programming techniques such as branching 
and looping, as well as an understanding of 
CMS procedures, CMS commands, and the CMS 
Editor. 



This book contains four major sections 
and an Appendix: 

• The "Introduction" discusses the EXEC 
facilities and their relationship to the 
VM/370 system. It also tells how to 
invoke and create an EXEC procedure. 

• "Using the CMS EXEC Facilities" 
describes the three parts of the CMS 
EXEC facilities: 

- The EXEC command. 

- The EXEC files. 

- The EXEC interpreter. 

• "EXEC Control Statements" defines three 
types of EXEC statements (execution 
control, built-in functions, and special 
variables) , and describes each control 
statement in detail. This section 
contains the main portion of the 
reference material in the book. 



• "Appendix A: EXEC Control Statement 
Summary" provides a quick-reference 
summary of the EXEC control statements, 
which you may find helpful after you 
have learned to use them. 

Examples of EXEC statements and 
procedures are found throughout this book, 
but they are concentrated in the "Building 
EXEC Procedures" section. You can refer to 
this section for examples as you read the 
control statement descriptions, or you can 
read the entire book once from front to 
back, then use the "EXEC Control 
Statements" section and "Appendix A: EXEC 
Control Statement Summary" for reference 
purposes. 

Users of the IBM 3277 Display Station 
(also called the "3270") should note the 
3270 equivalents of terms in this book that 
refer to IBM 2741 Communication Terminals. 
These are as follows: 

• The equivalent of the RETURN key on a 
2741 is the EHTER key on a 3270. 

• Output that is "typed" at a 2741 is 
"displayed" at a 3270. 

Because there is no TAB key on a 3270, 
one of the 3270 program function keys 
should be set to define tab characters. 

The differences between 3270s and 2741s 
are fully described in the IBM Virtual 
Machine Facility/370: EDIT Guide, Order Ho* 
GC20 r 1805. 



PREREQUISITE PUBLICATIOH 



"Building EXEC Procedures" illustrates 
several techniques of EXEC design. This 
section shows you how to create EXEC 
procedures and control their execution. 
It contains most of the examples to be 
found in this book. 



The IBM Virtual Machine Facilit y/370: EDIT 
GuideT Order Ho. GC20-1805, is a 
prerequisite for understanding the use of 
the CHS Editor and EDIT subcommands, which 
you will need in order to create EXEC 
procedures. 
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HER OPERANDS FOR 8C0HTR0L 



New: Program Feature 



Two new operands, HSG and NOHSG, have 



statement. 



DOCUHEHTATIOH CHARGES 



The information about PROFILE EXEC 
procedures, return codes, stacking, 
EXEC file record lengths, and EDIT 
macros has been clarified. 



&EXEC SPECIAL VARIABLE 

Maintenance: Documentation Only 

We have included information about the 
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EDIT MACROS 

Maintenance: Documentation Only 

He have corrected the example of EDIT 
macro usage. 
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ASSIGNMENT STATEMENT 



Maintenance : Documentation Only 



This change clarifies the paragraph 
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11. This change also affects 
"Assignment Statements" on page 13 and 
the sample EXEC procedure on page 59. 



USE OF EXEC PROCEDURES FOR THE CMS BATCH 
FACILITY 



Maintenance: Documentation Only 



Summary of Amendments 

for GC20- 1812-0 

As Updated by GN20-2635 

VM/370 Release 1 PLC 13 



The EXEC procedure example on page 59 
of the section titled 'Building EXEC 
Procedures' is changed. 
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INTRODUCTION 



The CHS EXEC facilities enable you to define new CMS commands that are 
combinations of existing CP and CHS commands. The new commands, called 
EXEC procedures, are usually created using the CMS Editor. 

In some respects, an EXEC procedure provides facilities similar to 
those of an OS cataloged procedure. When an EXEC procedure is invoked, 
it represents a seguence of commands that are executed according to the 
logic control statements defined in the EXEC procedure. 

You can create simple EXEC procedures that execute several freguently 
used commands, or you can devise complex EXEC procedures that test 
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command. The logical capabilities in the EXEC processor are controlled 
with statements similar to the IF/THEN, GOTO, DO, and LOOP statements 
familiar to high-level language users. 

An EXEC procedure is created by placing a selected seguence cf 
commands in an EXEC file. An EXEC file can have any valid CHS filename 
and filemode, but it must have a filetype of EXEC. EXEC files are made 
up of fixed length records up to 130 characters long. Each record 
consists of one CHS command or EXEC control statement. (A CP command can 
be entered in an EXEC file by using the CHS command CP.) 

Although EXEC files are usually created by using the CHS Editor, they 
can also be created by an option of the LISTFILE command, by reading a 
card file from the user*s virtual reader, or by a user program. 



INVOKING AN EXEC PROCEDURE 
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the filename of the EXEC file wanted and, optionally, a list of 
arguments. When you are in CHS command mode, you may omit the initial 
word EXEC, thus invoking the EXEC procedure simply by entering the 
filename. 

You can invoke an EXEC procedure by filename because when a CHS 
command is entered at a terminal, CHS first searches for an EXEC 
procedure by that name, then for a regular CMS command module by that 
name. Therefore, if an EXEC procedure has the same name as a CHS 
command module, the EXEC procedure is always executed instead of the 
command. The CMS command of the same name can then be invoked within 
the EXEC prodedure. 

Note: When a CHS command is issued in a user program, the request is 

handled by an SVC (Supervisor Call) , and the search of EXEC procedures 

is not made. In this case, an EXEC procedure can be invoked 
explicitly. 

When an EXEC file is invoked, the EXEC interpreter controls the 
execution of the procedure, substituting values for EXEC variables where 
required, and passing control to CHS for execution of CHS commands. 
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The EXEC interpreter can manipulate argument lists, thus allowing the 
user to pass arguments to the EXEC procedure when it is invoked. Before 
a command in the EXEC file is executed, each variable in it is 
temporarily replaced by the corresponding argument from the argument 
list that was specified when the EXEC procedure was invoked. Use cf 
these variable arguments thus permits great flexibility in command 
execution within the EXEC procedure. 

The concepts introduced in the preceding paragraphs are discussed in 
greater detail later in this book. At this point, however, you can see 
that the EXEC facilities provide you with a powerful tool that you can 
use to develop your own command language or set cf operating 
procedures. 



OIlIJiG kl JXJC PROCEDURE 

Once you have designed an EXEC procedure, you can enter it into the 
VM/370 system in several ways: 

1. By punching cards, which are then read via the real system card 
reader and the user's virtual reader. 

2. By using the CMS Editor to enter input lines into a CMS file. 

EXEC files can also be created by a user program or by the CMS 
LISTFILE command. Regardless of which method is used, the format of the 
entered statements is basically the same. Only one CMS command or EXEC 
control statement may be entered per card or card image. CMS commands 
must be in the same format as they would be if you entered them from a 
terminal. - 

To use the CMS Editor to create an EXEC file, enter the command: 

EDIT filename EXEC 

where the filename is any valid CMS filename. The filetype of EXEC is 
required. The CMS Editor automatically places a limit of 80 characters 
on the input line length, and translates all entered lowercase 
characters to uppercase. 

If the EXEC file specified in the EDIT command is a new file, the 
message: 

NEW FILE: 
EDIT: 

is displayed at the terminal. You can then type in the INPUT subcommand 
and start entering input lines as soon as the Editor replies, as 
follows: 

input 

INPUT: 

(Begin entering input lines.) 

End each input line by pressing the RETURN key (or the ENTER key on a 
3270 display station) . When you have finished entering input, return to 
EDIT mode by pressing the RETURN key again. If the file needs no 
corrections, you can save it by typing in the FILE subcommand. The data 
is stored and control returns to the CMS environment. 
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You can execute an EXEC file created in this way by typing in "EXEC 
filename", or simply by typing in the filename. You can examine its 
contents either by displaying it at a terminal using the CMS TYPE 
command, or by printing it on the system printer using the CMS PRINT 
command. 

The preceding description of the CMS Editor identifies only a few of 
the Editor functions that may be useful in creating and editing EXEC 
files. For a more complete discussion of the CMS Editor, refer to the 
VMZ370: EDIT Guide. 



Introduction 



USING THE CMS EXEC FACILITIES 



This section describes the three major parts of the CMS EXEC facility: 

1. The EXEC command, which initiates CMS execution of an EXEC file. 

2. The EXEC files, which contain sequences of CMS commands and EXEC 
control statements. 

3. The EXEC interpreter, which analyzes each statement in an EXEC file 
before CMS executes the procedure. 

Each of these items is described in greater detail under a separate 
heading. 



THE EXEC COMMAND 

The EXEC command executes one or more CMS commands or EXEC control 
statements contained in a specified EXEC file, allowing a sequence of 
commands to be executed by issuing a single command. If this conimand is 
entered from the CMS command mode, but not nested within another EXEC 
procedure, the initial word EXEC may be omitted. This technique is 
known as "implied EXEC." The format of the EXEC command is: 



i 1 

| EXec \ fname [args.*.] I 

i 1 



fname specifies the filename cf a file containing one or more CMS 
commands to be executed. The filetype of the file must be EXIC 
and the file must be fixed format, with a logical record length 
of up to 130 characters. 

args specify the arguments to replace the numeric variables in the 
specified EXEC file. Within an EXEC file, up to thirty symbolic 
variables may be used, each one indicated by an ampersand (6) 
followed by an integer ranging from 1 to 30, to indicate values 
which are to be replaced when the EXEC file is executed. 

The EXEC interpreter assigns the arguments to symbolic 
variables in the order in which they appear in the argument 
list. For example, each time an 81 appears in a line within the 
EXEC, the first argument specified with the EXEC command 
temporarily replaces the 81, the second argument specified with 
the EXEC command replaces 82, and so on, to the nth argument cf 
the EXEC command. 

If the percent sign (%) is used in place of an argument, the 
EXEC interpreter ignores the corresponding variable in all the 
commands that refer to that variable. If the EXEC file contains 
more variables than arguments given with the EXEC command, the 
EXEC interpreter assumes that the higher-numbered variables are 
missing, and CMS ignores the higher-numbered variables when it 
executes the command. 
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EXEC FILES 

An EXEC file is a CMS data file that can contain CMS commands and EXEC 
control statements. 

EXEC files can be created with the CMS Editor, by punching cards, by 
a user program, or by the CMS LISTFILE command. An EXEC file can 
contain up to 4096 lines. When you create an EXEC file using the CMS 
Editor, the record length defaults to 80 characters, unless you use the 
LRECL option of the EDIT command to specify up to 130 characters. 
However, the EXEC interpreter only processes the first 72 characters of 
the records (no matter what the record length actually is) unless you do 
one of the following: 

1. Specify &BEGPUNCH ALL, to give you access to the first 80 
characters of each record that follows, up to the next SEND control 
statement. 

2. Specify 8BEGTYPE ALL or &BEGSTACK ALL, to give you access to all 
130 characters of each record that follows, up to the next &END 
control statement. 

If you do not specify the ALL option, EXEC will use only 72 characters 
of each record. 

If you have a command line longer than 72 characters, you can stack 
that command following an SBEGSTACK ALL statement. This will enable ycu 
to issue a command line up to 130 characters long. 

EXEC files consist of two types of statements: executable and 
nonexecutable. Each type is discussed below. 



NONEXECUTABLE STATEMENTS 

A nonexecutable statement in an EXEC file is one that begins with an 
asterisk (*) and may or may not contain text. These statements are for 
use as comment statements and are ignored during EXEC interpretation and 
processing. 



EXECUTABLE STATEMENTS 

An executable statement in an EXEC file is any statement that does not 
begin with an asterisk. These statements consist of data items which 
are strings of contiguous nonblank characters separated by blanks. Four 
classes of executable statements are recognized by the EXEC interpreter: 

1. Null statements. 

2. CMS commands. 

3. Assignment statements. 

4. Control statements. 

Each of these statement classes is discussed under a separate 
heading. In addition, labels, user-defined variables, and special EXEC 
variables are discussed in relation to assignment statements and control 
statements. 
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Hall Statement s 

A nail statement is an executable statement in which the number of data 
items is zero. A blank line is a null statement. 



Labels 

A label in an EXEC procedure begins with a hyphen (dash) , and contains 
up to seven additional alphameric characters. A label can be placed in 
front of (on the same line as) a CHS command or EXEC control statement. 
A label is often the object of a branching control statement, such as 
SGOTO or SLOOP. 



When searching for a label, the EXEC interpreter examines only the 
first word on a line. Therefore, avoid any label names that appear as 
the first word of a line within the scope of an SBEGPUBCH, &BEGSTACK, or 
SBEGTYPE control statement. 



CHS Commands 

The EXEC interpreter considers an executable statement as a CHS command 
if the first data item does not start with an ampersand or asterisk. (A 
label can precede a CHS command.) CHS executes the command immediately. 
When CHS finishes execution, it returns control to the EXEC file, and 
places the completion code from the CHS command in the special EXEC 
variable SBETCODE. 

Any valid CHS command may be included in an EXEC file. CP commands 
may be included by prefixing the desired command with the CHS "CP** 
command. Another EXEC procedure may be invoked by prefixing its 
filename with the CHS command "EXEC". 

Bote : When in CHS command mode, the commands CP and EXEC are not 
reguired; they can be implied. These prefixes are reguired only when 
these commands are invoked from an EXEC procedure or a user program, or 
when you have used the CHS command SET to set implied CP commands 
(IHPCP) or implied EXEC commands (IHPEX) off. 



Varia b les 

In an EXEC procedure you can use two types of variables: user-defined 
variables and special EXEC variables. 



User-defined variable names begin with an ampersand (&) add contain 
up to seven additional characters. These variables can contain numeric 
or alphameric data, and must be initialized by the user. They can be 
used for almost any purpose, much as user-defined variables in a 
high-level language program are used. 
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Special EXEC variables follow the saae naming conventions as 
user-defined variables, and also contain the saae types of data (numeric 
or character values) . The special EXEC variables, however, are 
initialized and set by the EXEC interpreter. The user can examine their 
contents, but in general, he cannot change thea. 



Variables are used extensively in assignment statements, which are 
discussed next. 
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Assignment Statements 

An assignment statement is a statement in which a variable symbol is 
assigned a value. The statement takes the form: 



i 1 

| &variable = ae I 

i i 

8variable is a variable symbol which must be preceded by the ampersand 
and followed by a blank. 

ae is an arithmetic expression, the value of which is assigned 

to &variable each time the statement is executed. ae must 
be preceded by a blank and may be any of the following: 

1. A single data item, such as ABC or 194. 

2. An arithmetic expression, consisting of a sequence of 
data items that possess positive or negative integral 
values and are separated by plus or minus signs, such 

as 3 - M -11 - 00. 

3. A built-in function followed by its arguments, for 
example, &SUBSTR &1 2 1. (Built-in functions are 
discussed under a separate heading.) 

As in other programming languages, the result of the expression to 
the right of the equal sign is placed in (assigned to) the variable 
named on the left of the equal sign (the target) . 

Leading zeros can be removed from a numeric quantity by performing 
some 3rii.uS8i.ic operation on x«. snu assigning «-ue result. i_o some 
variable. For example, the statements: 

5X = 00012 
&TYPE &X 
&X = &X + 
&TYPE &X 

result in the printed lines: 

00012 
12 

when the statements are executed in an EXEC procedure. 

Note: The data item immediately following the target of an assignment 
statement must be a literal equal sign (=) , and not an EXEC variable 
that has the value of an equal sign. Conversely, if an equal sign is to 
be the first data item following an EXEC control word (see "Control 
Statements" below) , then it must be specified as an EXEC variable that 
has the value of an equal sign, and not as a literal equal sign. 
Otherwise, the statement is interpreted as an assignment statement, and 
(if it is valid as such) the control word is thereafter treated as a 
variable. 
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Control Statements 

An executable statement is a control statement if the first data item is 
an EXEC control word and the second data item is not an equal sign, 
except that a control statement may be preceded by a label. Examples of 
control words are: 

SGOTO 
&EXIT 
GIF 

Control statements begin with a control word, which is usually 
followed by a list of data items and, in some cases, by additional lines 
of data. Control statements provide the means by which the user can 
control the execution of his EXEC procedure. The &IF control word, for 
example, can establish a conditional test, and a branch (SGOTO) can be 
taken if the test condition is met. Techniques for controlling EXEC 
logic are described in the section entitled "Building EXEC Procedures." 
The control words, and the rules for their use, are described 
individually in a later section entitled "EXEC Control Statements." 



THE EXEC INTERPRETER 

The EXEC interpreter examines each statement in an EXEC file when the 
file is invoked for execution. Except where specifically stated 
otherwise, data lines read from an EXEC file are truncated at column 72, 
and lines read from a terminal are truncated at column 130. All 
nonexecutable statements (comments) are ignored. Executable statements 
are interpreted, one at a time, in the following sequence. 

1. Except for those commands that accept a line of data (an arbitrary, 
unsubstituted, collection of words) as an argument, the words 
forming a statement are "tokenized." That is, each word is treated 
as an eight character quantity and is padded with blanks or 
truncated, as necessary. 

2. The tokens are then searched for the names of any special EXEC 
variables, which are replaced by their values. However, if a token 
is the target of an assignment statement, the name of the variable 
is retained. Tokens in a statement are then searched for the names 
of user-defined variables, which are replaced by values as follows: 

• Each token is scanned for ampersands (S) , starting with the 
rightmost character of the token. 

• If an ampersand is found, then it, with the rest of the token to 
the right, is taken as a name. Then: 

IF it is the name of an active variable, 

THEN it is replaced (in the token) by the value assigned to the 
variable; 

IF it is the name of an EXEC keyword, 
THEN it is left unaltered; 

ELSE it is replaced (in the token) by blanks. 

An EXEC keyword is a control word, a built-in function, or 
either of the special tokens &$ and 8*. Any token formed is 
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padded with blanks or truncated (as necessary) to maintain a 
length of eight characters. 

Scanning resumes at the next character to the left, and the 
procedure is repeated until the token is exhausted. However, if 
the token is the target of an assignment statement, scanning for 
ampersands effectively stops before the leftmost character of 
the token is reached, because a variable name must be retained 
as the assignment target. 
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Note that any characters that are substituted are not scanned 
for ampersands. They are, however, included in the next name if 
another ampersand is found to the left. 

This processing makes it possible to simulate the effects of 
subscripted variables. For example, the sequence: 

&X = 123 

&TYPE ABC &X ABC&X 000000&X 

yields the printed line: 

ABC 123 ABC123 00000012 

The sequence: 

Entered After Substitution 

SI = 2 

&X&I = 5 &X2 = 5 

&I = &I - 1 &I = 1 

&X&I = &I + 1 SX1 = 2 

&X = &X&I + &X&X&I &X = &X1 + 5X2 or &X = 2 + 5 
STYPE ANSWER IS SX 

yields the printed line: 

ANSWER IS 7 

3. If at this point a token is entirely blank, it is discarded from 
the statement. The next token is deemed to immediately follow the 
previous one. 

A final token of blanks is added to any EXEC statement that is 
syntactically invalid if doing so makes the statement syntactically 
valid. For example: 

&BLANK = 

STYPE 

SLOOP 3 SX NE 

4. The statement is analyzed syntactically, and either passed to CMS 
or executed. When control returns from CMS, or the EXEC control 
statement has been executed, the EXEC interpreter examines the next 
statement in the file. 

Note: The substitution process is performed each time a statement is 
interpreted. Thus, a variable could contain a different value each time 
the statement containing the variable is interpreted. In this way, the 
same line can be executed as an entirely different statement on 
different occasions. For example, in the following EXEC procedure: 

&ARGS ASSEMBLE MYFILE 

&SKP = 

-EX &1 &2 S3 &4 

SSKIP SSKP 

SARGS PRINT MYFILE LISTING 

SSKP = 3 

SGOTO -EX 
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ths statement labeled -EX is executed the first time as: 

ASSEMBLE MYFILE 
and the second time as: 

PRINT MYFILE LISTING 
at which point the 6SKIP statement branches to the end of the EXEC file. 
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EXEC CONTROL STATEMENTS 



The EXEC control statements are grouped into three main categories: 

• Execution control statements, which control the logic flow of the 
EXEC procedure. 

• Built-in functions, which provide special services to the EXEC user. 

• Special variables, which contain particular values or perform 
specific functions during EXEC processing. 

Each of these categories is discussed in this section. The 
individual control statements are discussed under the category headings. 



EXECUTION CONTROL STATEMENTS 

The execution control statements determine what is to be done within an 
EXEC procedure. They are used to control logic flow; to communicate 
with a terminal, a user program, or the VM/370 system; or to create 
output files via the user's virtual punch. 

Each of the execution control statements is fully described under a 
separate heading, including syntactic specifications. They are presented 
in alphabetical order. Usage examples and implementation techniques and 
suggestions are found in the section entitled "Building EXEC 
Procedures. " 



SARGS CONTROL STATEMENT 

The &ARGS control statement allows the user to redefine the value of one 
or more arguments during EXEC processing. The format of the &ARGS 
control statement is: 



I 5ARGS | [argl [arg2 ... [argn] ] ] 



SARGS is used to redefine the variables &1, &2, ..., &n with the 
values specified by argl, arg2, ..., argn, and reset the special 
variable SINDEX to the number of variables thus redefined. Up to 18 
numeric variables can be redefined by an SARGS control statement. The 
remaining variables (through &30) are set to blanks. (The &READ control 
word can be used to read a list of arguments from the terminal.) 
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&BEGPUNCH CONTROL STATEMENT 



The &BEGPUNCH control statement heads a list of one or more lines to bt, 
spooled to the user's virtual punch. The list of lines to be punched is 
followed by the control statement SEND. The format of the &BEGPUNCH 
control statement is: 



| SBEGPUNCH | [ALL] 
y. 



| linel 

< line2 

< 

< 

| linen 

^ 

| SEND 



SBEGPUNCH punches linel , line2, . .., linen to the card punch, without 
tokenizing them. No substitution is performed on any untokenized data. 
The lines are normally truncated at column 72 and padded with blanks to 
fill an 80— column card; truncation can be avoided by specifying the 
option ALL, in which case data can occupy columns 73 to 80. The list of 
lines to be punched is terminated by a line in which the control 
statement SEND starts in column 1. (The &PUNCH control word can be used 
to spool a single line of tokens to the punch.) 



&BEGSTACK CONTROL STATEMENT 



The &BEGSTACK control statement heads a list of one or more lines to be 
placed in the user's console input stack. The list of lines to be 
stacked is followed by the control statement SEND. The format of the 
SBEGSTACK control statement is: 



i — 

I 

I 

I 

I 

t~ 

I 

< 

< 

< 

I 



I 

SBEGSTACK | 

I 



linel 
line2 



linen 

SEND 



r 1 r t 

| FIFO | | ALL | 

|LIF0| «- J 

L J 



> 
> 
> 

I 



SBEGSTACK stacks linel, line2, ...» linen in the terminal input 
buffer, without tokenizing them. No substitution is performed on any 
untokenized data. The lines are normally stacked FIFO (first in, first 
out) , but this can be changed by specifying the option LIFO (last in, 
first out). The lines are normally truncated at column 72, but this can 
be avoided by specifying the option ALL, in which case data can occupy 
columns 73 to 130. The list of lines to be stacked is terminated by a 
line in which the control statement SEND starts in column 1. (The SSTACK 



18 IBM VM/370: EXEC User's Guide 



control word can be used to place a single line of tokens in the console 
input buffer.) 



&BEGTYPE CONTROL STATEMENT 

The &BEGTYPE control statement heads a list of one or more lines to be 
typed on the user's terminal. The list of lines to be typed is followed 
by the control statement SEND. The format of the &BEGTYPE control 
statement is: 



« 1 

| &BEGTYPE | [ALL] | 

| . , 

| linel | 

< line2 > 

< : > 

< * > 

| linen | 

1 &END | | 



.j 



&BEGTYPE types linel, line2, ...» linen at the user's terminal, 
without tokenizing them. No substitution is performed on any 
untokenized data. The lines are normally truncated at column 72, but 
this can be avoided by specifying the option ALL, in which case data can 
occupy columns 73 to 130. The list of lines to be typed is terminated 
by a line in which the control statement &END starts in column 1. (The 
STYPE control word can be used to type a single line of tokens at the 
terminal.) 



SCONTINUE CONTROL STATEMENT 

The SCONTINUE control statement instructs the EXEC interpreter to 
process the next statement in the EXEC file. The format of the SCONTINUE 
control statement is: 



| SCONTINUE | I 



SCONTINUE is generally used in conjunction with an EXEC label (for 
example, -LAB SCONTINUE) to provide a branch address for &ERR0R, &GOTO, 
and other branching statements. SCONTINUE is the default action taken 
when an error is detected in processing a CMS command. 



SCONTROL CONTROL STATEMENT 

The SCONTROL control statement instructs the EXEC interpreter how to 
handle the typing of various information messages at the user's 
terminal. The format of the SCONTROL control statement is: 
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r t 


r t 


r n 


r i 1 


| SCONTROL 


|OFF | 


|TIME | 


IPACK | 


IHSG | | 




|ERRCR| 


|NOTIME| 


|NOPACK| 


|NOMSG| | 




ICMS | 


L J 


L J 


L J | 




|ALL | 










L J 









SCONTROL sets the characteristics of terminal typecut of execution 
messages until further notice. 

OFF Do not type any CMS commands as they are executed in this EXEC 
procedure, nor any return codes that may result. 

ERROR Type only those CHS commands that result in a nonzero return 
code, and type the return code. 

CMS Type each CMS command as it is executed, but type the return 
code only if it is nonzero. 

ALL Type every executable statement as it is executed, and type any 
nonzero return codes from CMS commands. 

TIME Include the time-of-day value with each CMS command printed in 
the execution summary. This operand is effective only if CMS cr 
ALL is specified. 

HOTIME Do not include the time-of-day value with CMS commands printed 
in the execution summary. 

PACK Pack the lines of the execution summary so that surplus blanks 
are removed from the typed lines. 

NOPACK Do not pack the lines of the execution summary. 

MSG Do not suppress the "FILE NOT FOUND" message if it is issued by 
the following commands when they are invoked from an EXEC 
procedure: ERASE, LISTFILE, RENAME, or STATE. 

NOMSG Suppress the "FILE NOT FOUND" message if it is issued when the 
ERASE, LISTFILE, RENAME, or STATE commands are invoked from an 
EXEC procedure. 

On entry to an EXEC file, the default settings for SCONTBOL are: 

CMS NOTIME PACK MSG 

Each operand remains set until explicity reset by another SCONTROL 
statement. 



&END CONTROL STATEMENT 

The SEND control statement marks the end of a list of one or more lines 
that began with an &BEGPUNCH, &BEGSTACK, or SBEGTYPE control statement. 
The format of the SEND control statement is: 



I SEND | 
i 
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The lines between the SBEGPUNCH, &BEGSTACK, or &BEGTYPE control 
statement and the terminating SEND control statement are handled as 
untokenized lines of data. The SEND control word must begin in column 1 
to be recognized as a termination instruction. 



&ERROR CONTROL STATEMENT 

The &ERROR control statenent specifies an action to be taken when a CMS 
command returns with an error return code. The format of the 6ERR0R 
control statement is: 

i 1 

| &ERROR | action I 
i i 



&ERROR tells the EXEC interpreter to perform the specified action 
following any CMS command that yields an error return code (that is, a 
return code that is not zero) . The action can be any executable 
statement. 

What happens next depends upon the type and conseguences of the 
action. If the action specified is a CMS command that also yields an 
error return code, then the EXEC interpreter types an error message and 
exits from the file; otherwise (unless the action causes a transfer of 
control) , execution resumes at the line following the CMS command that 
caused the action to be executed. On entry to an EXEC file, the action 
is set to continue processing (that is, &C0NTINUE) . 

The error message typed by the EXEC interpreter is: 

(811) ERROR IN 8ERRCR ACTION 

Additional information about this and other error messages is found 
under the heading "Recognizing EXEC Processing Errors" in the section 
entitled "Building EXEC Procedures." 

Note: The words following the &ERROR control word are saved in an 
unscanned format, and substitution for any variables among them is 
performed dynamically (if the occasion arises) after obtaining a nonzero 
return code from a subseguent CMS command. 



&EXIT CONTROL STATEMENT 

The SEXIT control statement causes an exit from the current EXEC file. 
The format of the &EXIT control statement is: 

i 1 

I I r -i I 

I SEXIT | | return-code | I 

I I I | I 

I I L J I 

i i 

SEXIT tells the EXEC interpreter to exit to the next higher level cf 
control with the specified return code. If the exit is taken from a 
nested EXEC procedure, control passes to the calling EXEC procedure. If 
the exit is taken from a first-level EXEC procedure, control passes to 
CMS. 
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If you do not specify a return code, a normal exit with a return code 
of zero is taken. You can specify the special variable SRETCODE to 
return the completion code from the most recently executed CHS command. 

Alternatively, in the 6EXIT control statement, you can specify your 
own variable, which you set to a numeric value earlier in the EXEC 



procedure. Then when you exit from 
appear as the return code. This can 
sets the variable to one value if it 
value if it executes another branch; 
which branch was executed. 



the procedure, this value will 

be useful if your EXEC procedure 

executes one branch and another 

the EXIT return code will shew 



SGOTO CONTROL STATEMENT 



The &GOTO control statement transfers control to a specific location in 
the EXEC procedure. Execution then continues at the location that is 
branched to. The format of the SGOTO control statement is: 



&GOTO 



TOP 

line— number 

label 



SGOTO transfers control to the top of the EXEC file, to a given line, 
or to the line starting with the specified label. 

The first character of a label must be a hyphen (minus sign) . You 
can attach a label to any executable statement as the first token oh the 
line. Scanning for a label starts on the line following the 6G0T0 
statement, goes to the end of the file, then to the top of the file, and 
(if unsuccessful) ends on the line above the SGOTO statement. If more 
than one statement in the file has the same label, the first one 
encountered by these rules satisfies the search. 

&GOTO is commonly used to branch based on some conditional test, such 
as an 8IF control statement. 



GIF CONTROL STATEMENT 



The EIF control statement allows you to conditionally execute statements 
in your EXEC procedure. The format of the SIF statement is: 



SIF 




EQ 
NE 
LT 
LE 
GT 
GE 




executable-statement 



&IF tells the EXEC interpreter to determine whether the condition 
expressed is true or false. If the condition is true, the executable 
statement is processed. If the condition is false, processing continues 
with the next line in the EXEC procedure. 
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The analysis of the conditional expression proceeds as follows: 

1. Tokenl and token2 are syntactically examined, and any substitutions 
to be made are performed. 

2. The tokens are compared according to the comparison operation 
specified. 

3. If the comparison is true, the executable statement is processed 

4. If the comparison is false, control passes to the next statement in 
the EXEC procedure. 

The executable statement can be any valid EXEC control statement or 
CMS command. (Another SIF control statement can be specified as the 
executable statement for up to three levels of nesting.) 

The special token S$ is interpreted as "any of the variables S1, &2, 
. ,.&n # " and the special token &* is interpreted as "all of the variables 
&1 , &2, ..., Sn." 

The comparison is arithmetic only when both comparands are numeric; 
in all other cases, a logical comparison is made. The comparison 
operators must be specified as shown. They are interpreted as follows: 

EQ equals 

NE not equal 

LT less than 

LE less than or equal to (not greater than) 

GT greater than 

GE greater than or equal to (not less than) 



SLOOP CONTROL STATEMENT 

The &LOOP control statement describes a loop through the EXEC procedure, 
including the conditions for exit from the loop. The format of the SLOOP 
control statement is: 



| SLOOP | 



U Um ) 
\ label) ( condition j 



&LOOP executes the following n lines, or down to (and including) the 
line starting with label, for m times, or until the specified condition 
is satisfied. A value must be specified for each parameter in the &LOOP 
statement. 

The values of n and m (if given) must be positive integers from to 
4095. 

The first character of the label name (if given) must be a hyphen, 
and the label must be specified, as the first token on the line, in an 
executable statement that lies below the SLOOP statement. 
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The syntax of the exit condition (if given) is the same as that in 
the &IF statement. The condition is always tested before executing the 
loop. Thus, if the condition is met, the loop is not executed. 

when loop execution is complete, control passes to the next statement 
following the end of the loop. Loops may be nested up to four levels 
deep. All nested loops may end at the same label, if desired. 



SPUNCH CONTROL STATEMENT 

The &PUNCH control statement causes a string of eight— character tokens 

to be directed to the user's virtual punch. The format of the &PUNCH 
control statement is: 



i 1 

| &PUNCH | tokl [tok2 ... [tokn]] | 

i , i 



&PUNCH punches a card containing the tokens tokl, tok2, ..., tokn. 
The card is padded with blanks or truncated, as necessary, to fill an 
80-column card. The tokens, as punched, are separated from each other 
by a single blank. Any tokens longer than eight characters are left 
justified and truncated on the right. 

To punch one or more lines of untokenized data, use the &BEGPUNCH and 
SEND control statements. 



&SEAD CONTROL STATEMENT 

The &READ control statement reads one or more lines of data from the 
user's terminal. The format of the &READ control statement is: 

, , ., 

r t I 

in I | 

\1 I I 

IARGS | | 

|VARS varl [ var2 ... [varn]] | | 

»- j i 



&READ 



8READ reads the next n lines from the terminal and treats them as if 
they had been in the EXEC file; or it reads a single line, assigns the 
tokens in it to the arguments &1, &2, ..., &n, and resets the special 
variable 6INDEX to the number of arguments thus set; or it reads a 
single line and assigns the tokens in it to the variables varl, var2, 
..., varn (this does not reset &INDEX) . 

If n is specified, reading from the terminal stops when n lines have 
been read, or when an &LOOP statement or a statement that transfers 
control is encountered. If an &READ statement is encountered, the 
number of lines to be read by it is added to the number outstanding. 
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The variables varf, var2, . .., varn, if specified, are scanned in the 
same way as if they appeared on the left— hand side of an assignment 
statement. If no variable names are specified, no data is read from the 
terminal. Any data entered is lost. 

If no operands are specified, &READ 1 is assumed by default. 



SSKIP CONTROL STATEMENT 

The SSKIP control statement causes a specified number of lines in the 



W tff -P-J 1 ^ 4- n Vi^ ^.^i-^-^^A (Til.^ -P y» •». m -. 4- ~-c 4-L„ ee 



KIP controj. statement is; 



1 1 

| &SKIP 


r ~\ 
! n | 




1 I 
1 I 


1 1 \ 

L J 





SSKIP passes over and ignores the next n lines of the EXEC file if n 
is greater than zero. If n is less then zero, &SKIP transfers control 
to the line that is n lines above the current line. If n equals zero, 
SSKIP transfers control to the next line. If end-of-file is reached 
during the skip operation, the EXEC file returns control to CMS. 

If n specifies a position before the beginning of the EXEC file, an 
error results. See the discussion of error messages under the heading 
"Recognizing EXEC Processing Errors" in the "Building EXEC Procedures" 
section. 

If no number is specified, &SKIP 1 is assumed by default. 



SSPACE CONTROL STATEMENT 

The SSPACE control statement types a specified number of blank lines at 
the user's terminal. The format of the SSPACE control statement is: 



I I r -i 

| SSPACE j | n | 

i i i a i 

i i «- j 

i , 



If no number is specified, SSPACE 1 is assumed by default. 
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SSTACK CONTROL STATEMENT 



The &STACK control statement causes a single data line to be stacked in 
the terminal input buffer. The format of the &STACK control statement 
is : 



| & STACK | I FIFO | 
I I |LIFO| 



[tokl [tok2 



[tokn ]]] 



SSTACK places a line in the terminal input buffer containing the 
tokens tokl, tok2, ..., tokn, or places a null line in the buffer if no 
tokens are specified. The line is normally stacked FIFO (first in, 
first out) , but this can be changed by specifying the LIFO option (last 
in, first out). The tokens, as stacked, are separated from each other 
by a single blank. 

You can stack CMS Immediate commands in the terminal input buffer, 
just as you can stack any other commands. In fact, you can stack any 
data at all in the terminal input buffer. The data need not be a valid 

command . 

Note: The Logical Line End character is a hexadecimal '15'. CMS 

routines do not process the symbolic pound sign (#) as a logical line 

end character (that is, do not translate it to X'15') unless the user 
does the following: 

1. Changes or turns off the Logical Line End character via the CP 
TERMINAL command. 

2. Uses the EDIT subcommand ALTER to cause the CMS Editor to 
automatically convert the # character (or some other character) to 

X • 1 5 • . 

To enter one or more untokenized lines into the terminal input 
Duffer, use the &BEGSTACK and &END control statements. 



&TIME CONTROL STATEMENT 



The &TIME control statement determines what timing information is typed 
at the user's terminal after each CMS command is executed. The format 
of the &TIME control statement is: 
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The STIME control statement can be used to type timing information in 

the form: 

T=x.xx/y.yy hh:ma:ss 
where: 

x.xx is the virtual CPU time used since it was last reset in 

the current EXEC file. 

y,yy is the total CPU time used since it was last reset in the 
current EXEC file. 

hh:mm:ss is the actual time of day in hours: minutes: seconds. 

The CPU times are set to zero before the execution of the first 
statement in the EXEC file, and are set to zero (reset) whenever timing 

information is printed. 

OH Resets the CPU times before every CMS command, and prints the 
timing information on return. If the SCONTROL control statement 
is set to CMS or ALL, the printing of the timing information is 
followed by a blank line. 

OFF Does not automatically reset the CPU times before every CMS 
command, nor does it print the timing information on return. OFF 
is the initial setting. 

RESET Performs an immediate reset of the CPU times. 

TYPE Types the current timing information (and resets the CPU times) . 



STYPE CONTROL STATEMENT 

The STYPE control statement prints a line of tokens at the user's 
terminal. The format of the STYPE control statement is: 



-\ 



I STYPE | tokl [tok2 ... [tokn]] I 



STYPE prints at the terminal a line containing the tokens tokl, tok2, 
..., tokn. The tokens, when typed, are separated from each other by a 
single blank. To print one or more untokenized lines at the terminal, 
use the SBEGTYPE and SEND control statements. 



fiUILT^IN FUNCTIONS 

An EXEC built-in function consists of the name of the function and, 
usually, a list of arguments. Built-in function names are EXEC 
keywords, and start with an ampersand. With the exception of &LITERAL, 
a built-in function is recognized only if it appears as a token 
immediately following the equal sign of an assignment statement. Each of 
the built-in functions is described under a separate heading. 
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SCOUCAT BUILT-IN FUNCTION 

The SCONCAT function creates a concatenated string of tokens to be 
assigned to a user-defined variable. The format of the SCONCAT function 
is: 



r- 



| SCONCAT | tok! [tok2 ... [tokn]] 



SCONCAT concatenates the tokens tokl, tok2, . .., tokn into a single 
token, with a maximum length of eight characters. This function is 
recognized only on the right-hand side of an assignment statement. For 
example: 

&A = ** 



SB = &CONCAT XX &A 45 
STYPE &B 

Results in the printed line: 

XX**45 

If the concatenated token is longer than eight characters, the data 
is left justified and truncated on the right. 



SDATATYPE BUILT-IN FUNCTION 

The SDATATYPE function determines whether the contents of the specified 
token is alphabetic or numeric data. The format of the SDATATYPE 
function is: 



| SDATATYPE | token 
i 



The result of the SDATATYPE function has the value NUM or CHAR, 
depending on the data type of the specified token. This function is 
recognized only on the right-hand side of an assignment statement. 



SLENGTH BUILT-IN FUNCTION 

The SLENGTH function determines the number of nonblank characters in the 
specified token. The format of the SLENGTH function is: 



i ■ ' 1 

| SLENGTH | token | 
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The result of the SLENGTH function is the number of nonblank 
characters in the specified token. This function is recognized only on 
the right— hand side of an assignment statement. 



SLITERAL BUILT-IN FUNCTION 

The &LITERAL function instructs the EXEC interpreter to handle the 
specified token literally, without substituting for any variables in it. 
The format of the SLITERAL statement is: 



| SLITERAL I token | 



The &LITERAL function causes the EXEC interpreter to use the literal 
value of the specified token without substitution. This function is 
recognized anywhere in an executable statement. For example: 

&x = ** 

STYPE SLITERAL SX EQUALS SX 

Results in the printed line: 

&X EQUALS ** 

SSUBSTR BUILT-IN FUNCTION 

The SSUBSTR function creates a substring of specified characters from a 
specified token. The format of the SSUBSTR function is: 



i SSUBSTR | token i [j] 



The result of the SSUBSTR function extracts part of the specified 
token that starts at character i, with length of j; or that starts at 
character i and runs to the end of the token if j is not specified. The 
values of i and j (if given) must be positive integers. This function 
is recognized only on the right-hand side of an assignment statement. 
For example: 

SA = SSUBSTR ABCDE 2 3 
STYPE SA 

Results in the printed line: 

BCD 
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SPECIAL VARIABLES 

EXEC special variables are of two types: numeric and keyword. The 
numeric variables are those from SO through S30. Keyword variables are 
those that have special meaning to the EXEC interpreter. They include 
the special variables S* and &$, which are used to define conditions in 
&IF and SLOOP control statements. The special variables are discussed 
under separate headings in alphabetical order. 

SEXEC SPECIAL VARIABLE 

The SEXEC special variable is the name of the EXEC file. This variable 
cannot be set explicitly by the user* but it can be examined and tested. 



&N SPECIAL VARIABLE 

The Sn special variable represents the numeric variables SO through S30. 
When an EXEC file is invoked, SO is set to its filename by the EXEC 
interpreter. The other numeric variables from S1 to S30 are initialized 
to arguments that are passed to the EXEC file (if any) . Each numeric 
variable can contain up to eight alphameric characters. 

The numeric variable Sn is ignored when n is negative or greater than 
30, or when n is greater than the number of arguments supplied when the 
EXEC command is issued. The numeric variables can be reset by either an 
&ARGS or SREAD ARGS control statement. 

An argument can be set to blanks by assigning it a percent sign (%) 
when invoking the EXEC procedure, in an SARGS control statement, or in 
an SREAD ARGS control statement. 



SGLOEAL SPECIAL VARIABLE 

The SGLOBAL special variable contains the recursion level of the EXEC 
interpreter. Since the EXEC interpreter can handle up to 19 levels of 
recursion, the value of SGLOBAL can range from through 19. This 
variable cannot be set explicitly by the user, but it can be examined 
and tested. 



&GL0EALN SPECIAL VARIABLE 

The SGLOBALn special variable represents the variables &GLOBAL0 through 
&GL0EAL9. These variables hold integral numeric values that can be set 
explicitly by the user. They are all initially set to 1. Onlike other 
EXEC variables, these can be used to communicate between different 
recursion levels of the EXEC interpreter. 

Note: The EXEC interpreter can handle up to 19 levels of recursion. 
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SINDEX SPECIAL VARIABLE 

The SINDEX special variable contains the number of arguments passed to 
the EXEC procedure. Since up to 30 arguments can be passed to an EXEC 
procedure, the value of 8IUDEX can range from through 30. 

Although the user does not set this variable explicitly, it is reset 
by an SARGS or 8READ ARGS control statement. SINDEX can be examined to 
determine the number of active arguments in the EXEC procedure. 



SLINENOM SPECIAL VARIABLE 

The SLINENUM special variable contains the current line number in the 
EXEC file. Since an EXEC file can contain up to 4096 lines, the value 
of SLINENUM can range from to U095, This variable cannot be set 
explicitly by the user, but it can be examined and tested. 



SREADFLAG SPECIAL VARIABLE 

The SREADFLAG special variable contains the value CONSOLE or STACK, 
depending on whether an attempt to read from the user's terminal would 
obtain a physical line from the terminal or a logical line from the 
terminal input buffer (console stack) . This variable cannot be set 
explicitly by the user, but it can be examined and tested. 



SRETCODE SPECIAL VARIABLE 

The SRETCCDE special variable contains the return code from the most 
recently executed CMS command. SRETCODE can contain only integral 
numeric values (positive or negative), and is set after each CMS command 
is executed. This variable can be examined, tested, and changed by the 
user, but changing it is not recommended. To specify a return code en 
exit from an EXEC procedure, use the SEXIT control statement. 



STYPEFLAG SEECIAL VARIABLE 

The STYPEFLAG special variable contains the value RT (resume typing) or 
HT (halt typing) , depending on the value of the console output flag. 
This variable cannot be set explicitly by the user, but it can be 
examined and tested. 
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DSERrDEFIHED VARIABLES 

An EXEC user can define and manipulate his own variables in an EXEC 
procedure. The name of a user-defined variable oust begin with an 
ampersand (6) that is followed by a string of up to seven alphameric 
characters, at least one of which is not a number. 



When you choose a name for a variable, be careful not to choose a 
name that is an EXEC special variable (&EXEC, &RETCODE, etc.) . 

The EXEC subcommands that begin with an ampersand can also be used as 
user variables, but then they will not be executed as subcommands. For 
example, if you specify: 

STIPE = QUERY 
&TYPE USERS 

the EXEC interpreter will execute the command: 

QUERY USERS 



User-defined variables can be used for any purpose in an EXEC 
procedure, and can contain any type of data. The user is, therefore, 
responsible for validating any data in a variable before using it. For 
example, a character variable should not be added to a numeric variable 
under normal circumstances. 



A user variable is most often defined by entering it into the EXEC 
file as the receiving field of an assignment statement. It is usually 
initialized by the expression that makes up the other half of the same 
assignment statement. For example, to define a counter and initialize 
it to 99, the user could enter: 

SCOUHTER = 99 

This counter could then be manipulated by such control statements as: 

&LOOP -LOOPEHD SCOUNTER LE 
6C0UKTER « SCOUHTER - 1 
-LOOPEND SCONTINUE 

This loop decreases the value of the counter by one each time through 
the loop, then exits when the counter value eguals zero. 



The user can define similar variables throughout his EXEC file. 
Further examples of user variables are found throughout the next 
section, "Building BXEC Procedures." 
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BUILDING EXEC PROCEDURES 



Previous sections have described the functions and syntax of the EXEC 
control statements, built-in functions, and special variables. This 
section shows you how to use these EXEC facilities, along with CMS 
commands, to simplify operation of your CMS virtual machine. Using EXEC 
procedures, you can: 

• Catalog freguently used sequences of commands, such as those used to 
asseiUij-L© or cospiiS a program. 

• Create interactive procedures for such purposes as form letters, 
teaching a new user about the system, or generating reports. 

• Control the execution of jobs by the CMS Batch Facility. 

• Define special EXEC files, called EDIT macros, that can be used by 
the CMS Editor. 

• Specify the operating characteristics of your virtual machine in a 
special EXEC file called the PROFILE EXEC. 

The following discussions illustrate some of the techniques you can 
use to create EXEC files and control their execution. 



EASSING A3GUKENTS TO AN EXEC PROCEDURE 

Arguments can be passed to an EXEC procedure in two ways: 

1. By specifying them when the EXEC file is invoked. 

2. By entering them from the terminal in response to an &READ ARGS 
control statement. 

In addition, arguments can be set. explicitly within the EXEC file by 
issuing an SARGS control statement. The arguments are assigned to the 
numeric variables &1, &2, ..., &n, and the special variable &INDEX is 
set to the number of arguments that are assigned to numeric variables. 

While up to 30 arguments can be passed to an EXEC file, only 19 
tokens can appear in any single EXEC statement. Thus, to pass arguments 
to all 30 numeric variables, you may need to use the &READ ARGS control 
statement. For example, to assign values to the 30 numeric EXEC 
variables, you could use the following EXEC statement: 

&READ ARGS 

This statement reads an input line from the terminal and assigns the 
arguments specified to their corresponding numeric variables. Thus, if 
30 arguments are entered in response, then all 30 numeric variables are 

set. 
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An argument can be set to blanks by assigning it a percent sign (%) 
when invoking the EXEC procedure, when issuing an SARGS control 
statement, or when responding to an SREAD ARGS control statement. For 
example, the statements: 

SARGS A % B 
STYPE S1 S2 ** S3 

result in the printed line: 

A ** B 

After the arguments have been assigned to their corresponding numeric 
variables, they can be examined, tested, and manipulated at will. Two 
useful tests are discussed under the next two headings. 

CHECKING FOR THE PROPER NUMBER OF ARGUMENTS 

Although you can pass up to 30 arguments to an EXEC procedure, it is 
more common for an EXEC procedure to be designed to expect a few 
specific arguments that determine how it is executed. 

One way to find out if all the expected arguments are present is to 
check the &INDEX special variable. For example, if you create an EXEC 
procedure that manipulates a CMS file, you may need to know the filename 
and filetype of the file. In this case, your EXEC procedure can check 
to make sure that at least two arguments are entered (which could be a 
filename and filetype) , as follows: 

&IF &INDEX LT 2 &EXIT 16 

The result of this statement is to execute the next instruction in 
the EXEC file if the value of SINDEX is equal to or greater than 2, or 
to exit from the current EXEC procedure with a return code of 16 if the 
value of &INDEX is less than 2. 

After you have determined that the number of arguments passed is 
correct, then you can examine the individual arguments for correctness. 



CHECKING FOR THE LENGTH OF AN ARGUMENT 



An argument passed to an EXEC procedure can be up to eight characters 
long. Arguments longer than eight characters are left justified and 
truncated on the right when they are assigned to their corresponding 
numeric variables. 

In many cases, you may know that an argument should be a specific 
number of characters. When the proper length of an argument is known, 
you can use the &LENGTH built-in function to see if the entered data is 
the correct length. For example, suppose that the first argument can be 
a number up to five digits long. In this case, you can make sure that 
this limit is observed by coding: 

&LIMIT = &LENGTH &1 

SIF &LIMIT GT 5 &EXIT &LIMIT 
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The result of these statements is to assign the length of the 
variable S1 to the user-defined variable SLIMIT, then if the value in 
SLIMIT is egual to or less than 5, execute the next instruction in the 
EXEC file. If the value of SLIMIT is greater than 5, an exit is taken 
from the EXEC procedure with a return code that specifies the erroneous 
value in &LIHIT. 

If your EXEC procedure expects an argument that is exactly five 
characters long, you can perform a similar test by changing the GT 
(greater than) v to NE (not egual) in the SIF statement. 

After the preliminary checking of arguments has been done, you can 
perform any other tests that seem necessary. In many cases, you may 
want to check for specific values. Some technigues for doing this 
checking are discussed under the next heading. 



CHECKING FOR A SPECIFIC ARGUMENT 

When your EXEC procedure expects a specific value to be passed in the 
argument list, you can check for the presence of the argument in two 
ways, depending on its positional importance. 

When the argument is expected to be in a specific location in the 
list, you can check for it in that position. For example, if you create 
an EXEC procedure to handle files with a specific filetype, you can make 
sure that the filetype is entered as the second argument. If the 
filetype you expect is ASSEMBLE, the checking statement could be: 

SIF S2 NE ASSEMBLE SEXIT 4 

In this case, if the second argument is ASSEMBLE, the next statement 
in the EXEC procedure is executed. Otherwise, an exit is taken with a 
return code of 4. 

When it does not matter where in the argument list the expected value 
appears, you could code: 

SIF S* HE ASSEMELE SEXIT 4 

In this case, the exit is taken only when none of the arguments 

passed has a value of ASSEMBLE. If any one of then is the character 

string ASSEMBLE, then the next seguential statement in the EXEC 
procedure is executed. 



COMMUNICATING WITH A TERMINAL 

One of the facilities available to the EXEC user is the ability to 
communicate with an interactive terminal. EXEC procedures can be 
designed to display informational messages, prompt the user for specific 
data, produce form letters, and perform other similar functions. This 
section shows you how to create EXEC control statements to do some of 
these things. 
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READING DATA FROM A TERMINAL 

When an EXEC procedure is invoked, arguments can be passed to it in the 
invoking command line. After the EXEC procedure begins execution, 
however, the only way you can pass new data to it from your terminal is 
in response to an SREAD control statement. For example, suppose you 
want to enter some CMS command under a particular set of circumstances, 
but not at any other time. You can avoid testing for the particular set 
of circumstances in the EXEC procedure by simply issuing the &READ 
control statement, as follows: 

SREAD 

The person at the terminal now has to decide what to enter. If the 
situation calls for the defined CMS command, it can be entered; if the 
required conditions are not met, he can simply press the Return key to 
enter a null line. The entered line is treated as though it had been in 
the EXEC file all along. 

If you want to read in some new arguments, simply code: 
SREAD ARGS 

The arguments entered at the terminal are tokenized and assigned to 
thair corresponding numeric variables (the first argument to &1, the 
second to S2, and so on). Up to 30 arguments can be entered in response 
to an SREAD ARGS control statements 

When you want to assign arguments to specific variables in the EXEC 
procedure, you can do this by coding: 

SREAD VARS Svarnamel Svarname2 [...] 

where Svarnamel is the name of the variable to which the first argument 
is assigned, &varname2 is the name of the variable to which the next 
argument is assigned, and so on. Since a line in an EXEC procedure can 
contain up to 19 tokens, up to 17 named variables can be set by the 
response to a single SREAD VARS control statement. 

Note: Be aware of the difference between SREAD RRGS and SREAD VARS. 
SREAD ARGS always assigns the response tokens to the numeric variables 
S1 , &2 , etc. SREAD VARS assigns the response tokens to the variables 
specified in the variable list. Thus, if you want to pass more than 30 
data items to the EXEC, you can assign the first 30 to the numeric 
variables with a response to SREAD ARGS, then assign as many more as 
desired to named variables with responses to SREAD VARS statements. 

Just as you can instruct an EXEC procedure to read data from your 
terminal, so can you have the EXEC procedure type data at your terminal. 
The next section shows you some of the techniques for typing data at a 
terminal. 
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TYPING DATA AT A TERMINAL 

An EXEC procedure can be coded to type three different kinds of data at 
a terminal: 

1. Lines of tokenized data, which are typed one at a time by the &TYPE 
control statement. 

2. Lines of untokenized data, which are typed by specifying the 
SBEGTYPE control statement, then the lines of data, then the &END 
control statement. 

3. Records from a CMS file, which are typed by specifying the CMS TYPE 
command with appropriate parameters. 

You can also check a special EXEC variable (&TYPEFLAG) to determine 
whether or not to send output to a terminal. For example, if the 
terminal has suppressed typing, it is a waste of system resources to 
send data to it. 

In addition to these methods of explicitly controlling typing of data 
at a terminal, the user can occasionally receive messages from the EXEC 
interpreter and CMS commands. You can control the typeout of some of 
these messages by specifying certain options of the SCONTROL statement, 
as described in the section on "Checking for Execution Errors." 



Typinci a Sincjle Line of Tokens 

The &TYPE control statement can be used to type a line of tokens at a 
terminal. The tokens can be user-defined variables, special EXEC 
variables, self-defining terms, or any of the 30 numeric variables. If 
a token in an &TYPE statement is longer than eight characters, it is 
left- justified and truncated on the right. 

To type a line of data to a terminal, for example, you could enter: 
&TYPE THIS IS THE MESSAGE 

These tokens are all self-defining terms less than eight characters 
long. The resulting typed line appears at the terminal as: 

THIS IS THE MESSAGE 

To type the value of an EXEC variable, simply enter the variable as 
one of the tokens in the &TYPE statement, as follows: 

&TYPE SINDEX &RETC0DE 

The terminal output will display the current values of &INDEX and 
&RETCODE. For example, 

3 

would type at the terminal if the current value of &INDEX is 3 and the 
current value of &RETC0DE is 0. 
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Up to 18 tokens can be typed by a single &TYPE control statement. If 
you want to type a line longer than 18 words, or if you want to type one 
or more lines of untokenized data, you can use the &BEGTYPE and &END 
control statements, which are described next. 

Note: If you want to type variable data, such as the value of &INDEX, 
you must use STYPE instead of SBEGTYPE. 



TyEiH3 M2£§ Than One Line of Data 

When you want to type a word longer than eight characters at a terminal, 
you need to use the &BEGTYPE control statement, since the &TYPE 
statement edits data items into 8-character tokens. One or more data 
lines can be specified between the SBEGTYPE statement and a following 
SEND control statement, which terminates the list of data lines. 

Under normal circumstances, data lines are truncated at column 72. 
If you want to type data lines longer than this (up to 130 characters) , 
you can specify the ALL option on the &BEGTYPE control statement, as 
follows: 

SBEGTYPE ALL 

data line of 85 characters 

data line of 108 characters 

data line of 63 characters 

&END 

This specification turns off the truncation at column 72, and permits 
the first two lines (of 85 and 108 characters) to type as specified. 

Because the data lines controlled by SBEGTYPE are not tokenized, no 
substitution for EXEC variables is made before typing begins. Thus, if 
you want to type the contents of an EXEC variable, you must use the 
STYPE control word (you cannot use SBEGTYPE) . For example, the entered 
lines: 

SBEGTYPE 

&INDEX ARGUMENTS WERE PASSED 

SEND 

would type at the terminal, when the EXEC procedure is executed, as 
follows: 

&INDEX ARGUMENTS WERE PASSED 

The SINDEX specification is not recognized as an EXEC variable 
because it appears in an untokenized data line. Note that if the STYPE 
control statement is used to type this data line, the word ARGUMENTS is 
truncated to eight characters, as follows: 

STYPE SINDEX ARGUMENTS WERE PASSED 
yields, when the value of SINDEX is 3: 

3 ARGUMENT WERE PASSED 

where the last letter of ARGUMENTS has been truncated. 

In addition to using the STYPE and SBEGTYPE control statements, you 
can use the CMS TYPE command to display part or all of a selected CMS 
file at a terminal. Use of the CMS TYPE command is discussed next. 
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You can use the CMS TYPE command to type part or all of a CMS file at a 
terminal. A complete description of the TYPE command is found in the 
VM/370; Command Language Guide for General Users, Order No. GC20-1804. 
For purposes of this discussion, however, you need to know that the the 
filename and filetype of the file to be typed must be entered- and that 
you can specify the lines where typing is to begin and end, as follows: 

TYPE filename filetype [begin [end]] 

The filename, filetype, begin, and end values can be specified when 
the EXEC file is created, or they can be coded as EXEC variables and 
assigned values when the EXEC procedure is executed. 

Note: If you do not specify a beginning line for typing the first line 
of the file is assumed. If you do not specify an ending line for 
typing, the last line of the file is assumed. 

Fcr example, to type the first 23 lines of a CMS file named PGM3 
ASSEFBLE at a terminal, you could create - an EXEC procedure that 
explicitly defines these values, as follows: 

TYPE PGK3 ASSEMBLE 1 23 

If you want to make your EXEC procedure more general, however, you 

can let the TYPE parameters be numeric variables that are assigned 

values when the command line is analyzed by the EXEC interpreter. For 
example, the line: 

TYPE &1 &2 &3 &4 

can be set up to type any part of any CMS file by invoking the EXEC that 
contains it with different arguments. If the name of the EXEC file 
containing this line is TYPEOUT, a specification of: 

TIPEOUT MYEILE EXEC 

causes all the lines in the CMS file named MYFILE EXEC to be typed at 
the requestor's terminal, while a specification of: 

TYPEOUT PGM9 COBOL 1 130 

causes lines 1 through 130 in the CMS file named PGM9 COBOL to be typed 
out at the requestor's terminal. 

Although the examples shown here do little more than the TYPE command 
itself, you can see how inclusion of a generalized CMS TYPE command in 
an EXEC file can extend the communication facilities between EXEC 
procedure and terminal. The EXEC procedure can find out what values to 
assign to the TYPE parameters by issuing an SREAD ARGS control 
statement, or by using arguments that were passed when the EXEC 
procedure was invoked. 

Before typing any data at a terminal, your EXEC procedure may want to 
check the output flag to make sure the terminal is receiving typed data. 
This procedure is discussed next. 
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?2§2i£i23 ££§ O^tgut Flag 

The special EXEC variable STYPEFLAG always contains one of two character 
string values, RT or HT. The RT characters mean that the terminal is 
accepting typeout, while the < HT characters mean that the terminal has 
suppressed typeout. Since the typeout to a terminal involves overhead in 
both CMS and CP, you can make more efficient use of system resources if 
you do not use CMS and CP functions when they are not required. 

When a terminal has suppressed typing, you can set up an EXEC control 
statement that avoids any attempt to type data at the terminal, as 
follows: 

&IF STYPEFLAG EQ HT &GOT0 -NOTYPE 
&TYPE ANY NUMBER OF DATA LINES 
-NOTYPE &CONTINUE 

The execution of this EXEC segment is determined by the setting of 
STYPEFLAG. If it contains the value RT, the branch to -NOTYPE is not 
taken, and the next instruction is executed. If it contains the value 
HT, the branch to -NOTYPE is taken, and no data lines are typed at the 
terminal. 

Note: While you cannot explicitly set the STYPEFLAG variable in your 
EXEC procedure, you can examine its contents at any time, and move its 
value to some other variable if desired. 



LOGIC CONTROL IN AN EXEC PROCEDURE 

Another major facility available to the EXEC user is the ability to 
control the execution of an EXEC procedure by testing conditions and 
branching to different statements based on the results of testing. This 
section shows you how to set up conditional execution paths in an EXEC 
procedure, including such techniques as IF/THEN, GOTO, and fixed loops. 



LABELS IN AN EXEC PROCEDURE 

In many instances, an execution control statement in an EXEC procedure 
causes a branch to a particular statement that is identified by a label. 
The rules and conventions for creating syntactically corrent EXEC labels 
are relatively simple: 

1. A label must begin with a hyphen (dash), and must have at least one 
additional character following the hyphen. 

2. Up to seven additional alphameric characters may follow the hyphen 
(with no intervening blanks) . 

3. A label name may be the object of an SGOTO or SLOOP control 
statement. 

4. A label that is branched to must be the first token on a line. It 
may stand by itself, with no other tokens on the line, or it may 
precede an executable CMS command or EXEC control statement. 
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The following are examples of correct use of labels: 

SGOTO -LAB1 

-LAB1 

-LAB2 SCQNTINUE 

-CHECK SIF &INDEX EQ SGOTO -EXIT 

&IF &INDEX LT 5 &SKIP 

-EXIT &EXIT H 

STYPE SLITERAL &INDEX VALUE IS &INDEX 

The following examples of label usage are incorrect for the reat. 
indicated : 

-LABELING More than 8 characters 
SSKIP -4LINES Not object of SGOTO or SLOOP 

No alphameric characters included 
&EXIT -EXIT Label not first token on line 

BLANKS Blanks between hyphen and other characters 

You will find that EXEC labels are useful in controlling the logic 
flow through your EXEC procedures. Further examples of label usage are 
found throughout the rest of this book. 



CONDITIONAL EXECUTION WITH THE GIF STATEMENT 

The main tool available to you for controlling conditional execution in 
an EXEC procedure is the SIF control statement. The &IF control 
statement provides the decision-making ability that you need to set up 
conditional branches in your EXEC procedure. 

One approach to decision-making with &IF is to compare the equality 
(or inequality) of two tokens, and perform some action based on the 
result of the comparison. When the comparison specified is true, the 
executable statement is executed. When the comparison is false, control 
passes to the next sequential statement in the EXEC procedure. An 
example of a simple SIF statement is: 

&IF 1 EQ 2 5TYPE MATCH FOUND 

Since the equality specified is false, the executable statement 
(&TYPE MATCH FOUND) is not executed, and control passes to the next 
statement in the EXEC procedure. 

Although this example is coded correctly, it is not very useful. In 
fact, most 8IF statements establish a comparison between a variable and 
a constant, or between two or more variables. For example, if a 
terminal user could properly enter a YES or NO response to a prompting 
message issued to him, you could set up &IF statements to check the 
response as follows: 

&READ ARGS 

&IF &1 EQ YES SGOTO -YESANS 

&IF &1 EQ NO SGOTO -NOANS 

STYPE &1 IS NOT A VALID RESPONSE (MUST BE YES OR NO) 

SEXIT 

-YESANS 



-NOANS 
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In this example, the branch to -YESANS is taken if the entered 
argument is YES; otherwise, control passes to the next SIF statement. 
The branch to -NOANS is then taken if the argument is NO; otherwise, 
control passes to the 8TYPE statement, which types the entered argument 
in an error message and exits. 

The test performed in an &IF statement need not be a simple test of 
equality between two tokens; other types of comparisons can be tested, 
and more than two variables can be involved. The tests that can be 
performed are: 

Symbol Meaning. 

EQ A equals B 

NE A does not equal B 

LT A is less than B 

LE A is less than or equal to B (not greater than) 

GT A is greater than B 

GE A is greater than or equal to B (not less than) 

The special tokens 8$ and 8* can be specified to include the entire 
range of numeric variables 81 through 830, as follows: 

• The special token 8$ is interpreted as "any of the variables 81, 82, 
..., 830." That is, if the value of any one of the numeric variables 
satisfies the established condition, then the &IP statement is 
considered to be true. The statement is false only when none of the 
variables fulfills the specified requirements. 

• The special token 8* is interpreted as "all of the variables 81, 82, 
..., 830." That is, if the value of each of the numeric variables 
satisfies the established condition , then the SIF statement is 
considered to be true. The statement is false when at least one cf 
the variables fails to meet the specified requirements. 

If an 8IF statement specifies a special token (8* or 8$) that is null 
because no values were supplied for any of the numeric variables, the 
token cannot be successfully compared. The SIF statement is therefore 
considered a null statement. Execution continues at the next sequential 
statement. 

As an example of using special tokens, suppose you want to make sure 
that some particular value is passed to the EXEC. You can check to see 
if any of the arguments satisfy this condition, as follows: 

SIF 8$ EQ PRINT &SKIP 2 

STYPE FABM LIST MUST INCLUDE PRINT 

SEXIT 

In this example, the path to the &TYPE statement is taken only when 
none of the arguments passed to the EXEC equal the character string 
PRINT. 

The action to be executed as a result of SIF testing is frequently an 
SGOTO control statement. The next discussion examines the use of 8G0T0 
in conjunction with SIF, as well as by itself as an unconditional branch 
instruction. 
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BRANCHING WITH THE &GOTO STATEMENT 

The SGOTO options allow you to transfer control within your EXEC 
procedure in three ways: 

1. Directly to the top of the EXEC file (SGOTO TOP). 

2. To a particular line within the EXEC file (&GOTO linenum, where 
linenum specifies the line number to which control is passed) . 

3. To a specified EXEC label somewhere in the EXEC file (&GOTO label, 
where label specifies the label to which control is passed) . 

The scan for a line number or label begins on the line following the 
&GOT0 specification, proceeds to the bottom of the file, then wraps 
around to the top of the file and continues to the line immediately 
preceding the &GOTO specification. 

If the label or line number is not found during the scan, an error 
exit from the EXEC procedure is taken and an error message is typed. If 
the label or line number is found, control is passed to that location 
and execution continues. 

The SGOTO control statement can be coded wherever an executable 
statement is permitted in an EXEC procedure. One of its common uses is 
in conjunction with the &IF control statement. For example, in the 
statement: 

&IF &INDEX EQ SGOTO -ERROR 

the branch to the statment labeled -ERROR is taken only when the value 
of the &INDEX special variable is zero. In all other cases, control 
passes to the next sequential statement in the EXEC procedure. 

Another common use of SGOTO is to specify where to pass control if an 
error occurs in CMS command processing. You can determine whether or 
not an error occurred in CMS command processing by examining the special 
variable &RETCODE, but you may want to perform this analysis in a single 
subroutine instead of checking the return code after each CMS command 
completes execution. To pass control to a subroutine labeled -FINDERR, 
for example, you could code the &ERROR control statement as follows: 

&ERROR SGOTO -FINDERR 

The use of the &ERROR control statement is more fully illustrated in 
the section on "Checking for Execution Errors". 

An SGOTO statement can also stand alone as an EXEC control statement. 
When coded as such, it forces an unconditional branch to the specified 
location. For example, to pass control unconditionally to the top of 
the EXEC procedure, simply enter: 

SGOTO TOP 

Further examples of SGOTO usage are found throughout the rest of this 
book. 
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BRANCHING WITH THE &SKIP STATEMENT 

The &SKIP control statement provides you with a second method of passing 
control to various points in an EXEC procedure. Instead of branching to 
a named or numbered location in an EXEC procedure, &SKIP passes control 
a specified number of lines forward or backward in the file. 

When you want to pass control to a point that precedes the current 
line, simply determine how may lines backward you want to go, and code 
SSKIP with the desired negative value. For example, to use &SKIP for 
loop control, you could enter statements as follows: 

SIF &INDEX EQ &EXIT 12 

&TYPE COUNT IS 61 

61 = 61 - 1 

&IF 61 GT &SKIP -2 

When this EXEC procedure is invoked, it checks to make sure that at 
least one argument was passed to it. If an argument is passed, it is 
assumed to be a number that indicates how many times the loop is to 
execute. The loop executes until the count in 61 is zero. If the 
argument entered is zero, the loop executes only once, typing out: 

COUNT IS 

If no argument is passed, an exit is taken with a return code of 12. 

Just as you can pass control backward using &SKIP, you can also pass 
control forward by specifying how many lines to skip. For example, to 
handle a conditional exit from an EXEC procedure, you could code the 
following: 

ftIF &RETCODE EQ &SKIP 
&EXIT &RETCODE 

where the branch around the &EXIT statement is taken whenever the value 
of &RETCODE equals zero. If the value of &RETCODE does not equal zero, 
control passes out of the current fiXEC procedure with a return code that 
is the nonzero value in &RETCODE. Note that when no SSKIP operand is 
specified, a value of 1 is assumed. 



USING COUNTERS FOR LOOP CONTROL 

A primary consideration in designing a section of an EXEC procedure that 
is to be executed a number of times is how the number of executions is 
controlled. One simple way to control the execution of a sequence of 
instructions is to create a loop that tests and modifies a counter. 

Before entering the loop, the counter is initialized to some value. 
Each time through the loop, the counter is adjusted (up or down) toward 
some limit value. When the limit value is reached (the counter value is 
the same as the limit value) , control passes out of the loop and it is 
not executed again. 

The example in the previous section, "Branching With the &SKIP 
Statement." uses a counter to control the execution of the loop. The 
counter in that example is the numeric variable 61, which is initialized 
by an argument passed when the EXEC procedure is invoked. Each time 
through the loop, the value in &1 is decremented by one. When the value 
of 61 reaches zero, control passes from the loop to the next sequential 
statement (in the example, control returns to CBS) . 
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There are several ways of setting, adjusting, and testing counters. 
Some ways to set counters are: 

• By reading arguments from a terminal, such as: 

SREAD VARS SC0UNT1 SC0UNT2 

• By arbitrary assignment, such as: 

SCOUNTER = 43 

• By assignment of a variable value or expression, such as: 

SCOUNTS = SINDEX - 1 

Counters can be adjusted up or down by any increment or decrement 
that Tieets your purposes. For example: 

SCOONTEM = &COUNTEM - &RETCODE 
&C0UNT1 = SCOUNT + 100 

Counters can be tested by the &IF control statement for a specific 
value, a r^nge of values, or a simple equality to zero. For example, 
suppose a counter should contain a value from 5 to 10 inclusive: 

SIF SCOUNT LT 5 &SKIP 

SIF SCOUNT LE 10 &SKIP 

&TYPE SCOUNT IS NOT WITHIN RANGE 5-10 

If the value of SCOUNT is less than 5, control passes to the &TYPE 
control statement, which types out the erroneous value and an 
explanatory message. If the value of SCOUNT is greater than or equal to 
5, r. he next statement checks to see if it is less than or equal to 10. 
If this is true, then the value is between 5 and 10 inclusive, and the 
typeout of the error message is skipped. 

further examples of counter usage for loop control are found 
throughout the rest of this book. 



LOOP CONTROL WITH THE SLOOP STATEMENT 

A convenient way of controlling execution of a sequence of EXEC 
statements is with the SLOOP control statement. An SLOOP statement can 
be set up in four ways: 

1. To execute a particular number of statements a specified number of 

times. 

2. To execute a particular number of statements until a specified 
condition is satisfied. 

3. To execute the statements down to (and including) the statement 
identified by a label a specified number of times. 

4. To execute the statements down to (and including) the statement 
identified by a label until a specified condition is satisfied. 
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The numbers specified for the number of lines to execute and the 
number of times through the loop must be positi¥e. In addition, if a 
label is used to define the limit of the loop, it must follow the SLOOP 
statement (it cannot precede the SLOOP statement) . 

The decision as to which form of the SLOOP statement is intended is 
based on the number of tokens in the statement after scanning and 
substitution for any EXEC variables. If the conditional form is 
intended, and the first comparand or the comparator is given in the form 
of an EXEC variable, then the value of the variable lust not be blank at 
the time the statement is interpreted. 

In the conditional form, the tokens forming the conditional phrase 
are saved in an unscanned format, so that substitution for any EXEC 
variables can be performed dynamically before each execution of the 
loop. For example, the statements: 

SX = 

SLOOP -END SX EQ 2 

SX = SX + 1 

-END STYPE SX 

are interpreted and executed as follows: 

1. The variable SX is assigned a value of 0. 

2. The SLOOP statement is interpreted as a conditional fcrm; that is, 
to loop to -END until the value of SX eguals 2. 

3. The variable SX is incremented by one and is then typed. 

4. Control returns to the head of the loop, where SX is tested to see 
if it eguals 2. If it does not, the loop is executed again. When 
SX does egual 2, control is passed to the EXEC statement 
immediately following the end of the loop (in this case, an exit 
from the EXEC procedure is taken) . 

The typed lines resulting from a execution of this EXEC are: 

1 

2 

at which time the value of SX eguals 2, and the loop is not executed 
again. 

Another example of conditional loop control is as fellows: 

SY = SLITERAL ASB 
SLOOP 2 .SX EQ SLITERAL . S 
SX = SSDBSTR SY 2 1 
STYPE SX 

These statements are interpreted and executed as follows: 

1. The variable SY is set to the literal ASB. 

2. The two statements following the SLOOP statement are to be executed 
until the value of SX is S. Notice the periods that precede the 
values to be compared in the SLOOP statement. The first time this 
statement is executed, the variable SX has not been initialized to 
any value and, therefore, is considered a null string. Since the 
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EXEC interpreter ignores null strings, a period has been added to 
the SX to give it a recognizable value. A period must also be added 
to the constant S so the two values can compare correctly. (Any 
character that is not significant to the EXEC interpreter can be 
used instead of a period.) 

3. The variable SX is set to the value of the second character in the 
variable SY, which is a literal ampersand (S) . 

4. The ampersand is typed once, and the loop does not execute again 
because the condition that the value of SX be a literal ampersand 
is met. 

Further examples of loop control with the SLOOP statement are found 
throughout this book. 
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CONTROLLING EXECUTION OF CMS COWHANDS 

CMS commands in an EXEC procedure can be executed sequentiall v , under 
control of EXEC control statements, or they can be placed (stacked) in 
the terminal input buffer for later execution. You already know how to 
set up an EXEC procedure to control execution of CMS commands, and also 
how to execute CMS commands sequentially. This section shows you how to 
stack CMS commands for later execution. 

PLACING A COMMAND IN THE CONSOLE STACK 

The &STACK control statement allows you to stack a line of tokens in the 
terminal input buffer (also called the console stack) . Normally, the 
line of tokens comprises a CMS command (or subcommand) and its 
parameters, although a null line can also be stacked by omitting the 
tokens. In fact, the data placed in the stack need not be a command at 
all. See the heading "An Annotated EXEC Procedure'* for an example of 
such stacking. 

Lines placed in the console stack by SSTACK are normally stacked FIFO 
(first in, first out), but you can explicitly specify LIFO (last in, 
first out) by entering LIFO as the first token following &STACK. 

Note: The Logical Line End character is a hexadecimal '15'. CMS 
routines do not process the symbolic line end character (#) . 

The stacking facilities are especially useful in designing EXEC 
procedures that use such CMS commands as EDIT. You can use the &STACK 
control statement to set EDIT subcommands in the console stack, then 
execute the EDIT command itself. For example, suppose you wanted to 
define a special filetype that is to contain uppercase and lowercase 
characters. Since the EDIT command assumes only uppercase characters 
for all filetypes except MEMO and SCRIPT, you need to specify the EDIT 
subcommand CASE M each time you edit a file with the special filetype. 
If the special filetype is called TABLE, you could use the following 
EXEC procedure to control the CMS EDIT command: 

SIF &INDEX LT 2 &EXIT 12 
&IF &2 NE TABLE &SKIP 
&STACK CASE M 
EDIT & 1 &2 &3 &4 &5 &6 

When this EXEC is invoked, it expects to find at least two arguments, 
although up to six may be passed. The first argument must be a 
filename, and the second a filetype. If fewer than two arguments are 
passed, an exit with a return code of 12 is taken. 

If the filetype specified (S2) is not TABLE, the next sequential 

statement is skipped. In this case, an EDIT command is issued by 

specifying the arguments that were passed to the EXEC procedure. An 
exit is taken on return from CMS. 

If the filetype specified is TABLE, control passes to the next 
sequential statement in the file. This statement stacks the EDIT 
subcommand CASE M in the terminal input buffer. When the EDIT command 
is issued (in the next statement) , the first time the Editor reads from 
the terminal buffer, it reads the CASE M subcommand. The person working 
at the terminal is thus freed from having to enter CASE M when editing a 
TABLE file. 
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If you want to stack one or more untokenized lines in the console 
stack, you can use the &BEGSTACK and &END control statements, which are 
discussed next. 

IH§§EtiM More Than One Line 

Using the &BEGSTACK and &END control statements, you can place 
untokenized lines of data in the terminal input buffer (also called the 
console stack) . Normally, a line consists of a CMS command (or 
subcommand) and its parameters. Since the line is untokenized, no 
substitution is performed by the EXEC interpreter before the line is 
placed in the console stack. 

As with the &STACK control statement, you can specify whether the 
lines are to be executed on a FIFO (first in, first out) or LIFO (last 
in, first out) basis. 

Lines of data are normally truncated at column 72, but you can 
specify the option ALL in the &BEGTYPE statement to extend the data 
entry area to 80 characters (or to 130 characters if the EDIT command 
specifies LRECL 130). 

Consider another example using subcommands of the CMS EDIT command. 
This time, in addition to allowing uppercase and lowercase characters, 
you want to set tabs at columns 1, 10, and 20, and you want the short 
prompting message to appear when an invalid EDIT subcommand is entered. 
Using a filetype of TABLE for files that require this special treatment, 
you could enter the EXEC procedure as follows: 

t/IF 5INDEX LT 2 SEXIT 12 

Sir &2 HE TABLE &GOTO -EDIT 

&BBGSTACK 

CASE M 

TABS2T 1 10 20 

SHORT 

&END 

-EDIT EDIT S1 &2 &3 &4 &5 &6 

The analysis of the arguments passed is similar to that discussed in 
the previous example for SSTACK. In this EXEC procedure, a branch is 
taken to the label -EDIT when the filetype specified in the variable S2 
is not TABLE. When the filetype is TABLE, control passes to the 
SBFGSTACK control statement, which places the lines down to &END in the 
console stack. The EDIT command is then executed. The first three 
lines read from the terminal buffer are the subcommands that were 
stacked there. Thus, the person working at the terminal is freed from 
having to enter the CASE M, TABSET 1 10 20, and SHORT subcommands when 
editing a TABLE file. 

You can check the status of the console stack within your EXEC 
procedure by examining the SREADFLAG special variable, which is 
discussed next. 
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Examining the Read Status Flag 

Daring EXEC processing, you may need to know whether or not any data 
lines are stacked in the terminal input buffer. You can determine this 
quickly and easily by examining the special variable &READFLAG. If 
&RE&DFLAG contains the value CONSOLE, the next attempt to read from the 
terminal obtains a physical line from the real terminal. If &READFLAG 
contains the value STACK, the next attempt to read from the terminal 
obtains a line from the terminal input buffer. 

Note: You cannot set this variable explicitly, but you can examine it 
and save its value in some other variable at any point in an EXEC 
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For example, if successful completion of an EXEC procedure requires 
at least one data line to be stacked in the terminal input buffer, you 
might set up the following test just before leaving the EXEC procedure: 

&IF &READFLAG EQ STACK &EXIT 

&TYPE PROCESS ERROR; NO LINES IN STACK 

&EXIT 16 

If at least one line is in the stack, the normal exit is taken with a 
return code of zero. When no lines appear in the stack, the value of 
&READFLAG is not STACK, so control passes to the following &TYPE 
statement, which types an error message and exits with a return code of 
16. 

Note: &READFLAG can contain only the two values CONSOLE and STACK. 



CHECKING FOR EXECUTION ERRORS 

It is usually good programming practice to check for errors during 
execution of a program. This is as true for EXEC procedures as it is 
for any formal programming language. Three major types of errors can be 
detected during EXEC processing: 

1. Errors in number, type, or contents of arguments passed to an EXEC 
procedure. Checking for these kinds of errors has already been 
discussed under the heading "Passing Arguments to an EXEC 
Procedure." 

2. Errors in CHS command processing. Checking for these kinds of 
errors is controlled by specifying an &ERROR control statement that 
passes control to an analysis routine whenever a CHS command error 
occurs. These techniques are discussed under the following 
headings, "Identifying Error Handling Routines" and "Checking for 
CHS Error Return Codes." 

3. Errors in EXEC interpreter processing. These kinds of errors 
usually result in an error exit from the EXEC procedure. The EXEC 
interpreter types an error message and a return code, and returns 
to CHS. The messages and return codes are discussed under the 
heading "Recognizing EXEC Processing Errors." 
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IDENTIFYING ERROR HANDLING ROUTINES 

When an error is detected in processing a CMS command, a return code 
indicating the severity of the error is passed back to the EXEC 
interpreter. The EXEC interpreter then activates the &ERROR control 
statement currently in effect. If none has been specified, &CONTINUE is 
assumed, and no error processing is performed. 

An &ERROR control statement can specify that any executable statement 
be processed when an error is recognized. However, if the action taken 
is itself a CMS command that also yields an error return code, the EXEC 
interpreter types an error message and exits from the EXEC procedure. 

Note: An &ERROR control statement must be set up before the CMS 
commands for which it is to handle errors are executed. Thus, the 
effect of an &ERROR control statement ranges from the point at which it 
is entered until the next 8ERR0R statement is encountered. 

A simple error action is to exit from the EXEC procedure, passing the 
return code from the CMS command back to the user. For example: 

SERROR SEXIT SRETCODE 

In another EXEC procedure, you may want to check the severity of the 
error before taking any action. For example: 

SERROR &IF SRETCODE LT 12 &GOT0 -FIX 
&EXIT SRETCODE 



-FIX (Analysis routine begins here.) 

When the value of SRETCODE is 12 or more, the branch to -FIX is not 
taken, and the SEXIT statement that follows is executed. When the 
return code is less than 12, the branch to the error analysis routine at 
-FIX is taken. 

Once control passes to the error analysis section of an EXEC 
procedure, you can test the SRETCODE special variable to determine what 
kind of error occurred. This technique is discussed next. 



CHECKING FOR CMS ERROR RETURN CODES 

When an EXEC procedure passes control to an error analysis routine, it 
is usually because the error discovered is not very serious, and may be 
one that can be contained by performing some corrective action. Before 
you can take any corrective action, though, you need to know exactly 
what the error is. One way to determine the cause of the error is to 
examine the return code in the special EXEC variable SRETCODE. 
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For example, suppose you want to set up an analysis routine to 
identify return codes 1 through 11 (anything greater than 11 is set up 
to cause an immediate exit) . When a return code is identified, control 
is passed to a corresponding routine that attempts to correct the error. 
You could set up such an analysis routine as follows: 

-ERR&NAL 

&CNT = 

SLOOP 2 &CNT EQ 12 

GIF SRSTCODE EQ &CNT &GOTO -FIX&CNT 

SCST = &CNT + 1 



-FIXO &GOTO -ALLOK 

-FIX1,,* 

-FIX2. . . 



-FIX10. . . 
-FIX11. . . 
-ALLOK.. . 

When the value of the &CNT variable equals the return code value in 
&RETCODE, the branch to the corresponding -FIX routine is taken. Each 
corrective routine performs actions depending on its code. 

Shen you want to pass the value of &RETCODE out of the EXEC 
procedure, you can simply specify it in the SEXIT statement, as follows: 

&EXIT &RETCODE 

Further examples of the use of the &RETCODE special variable are 
found throughout the rest of this book. 



RECOGNIZING EXEC PROCESSING ERRORS 

Just as errors can occur in CMS command execution, so can they occur in 
EXEC control statement processing. When the EXEC interpreter finds an 
error, it types the message: 

ERROR IN EXEC FILE fname, LINE nn — error description 

where: 

fname 

is the filename of the EXEC file in which the error was detected. 

nn 

is the line number in the file at which the error occurred. 

error description 

is one of the conditions described below. A return code is passed 
back to the calling program; the return codes are shown with the 
messages to which they belong. 
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Return 

£2d6_ Message and Explanation 
802 ~ &SKIP OR &GOTO ERROR 

An error occurred in attempting to process an &SKIP or &GOTO 
statement. For &SKIP, a value that specifies a position 
before the beginning of the EXEC file may have been 
sp£cified. For &GOTO, the target specification may have been 
omitted. 



804 TOO MANY ARGUMENTS 

The user has tried to pass more than 30 arguments to the 
specified EXEC at the line indicated. If more than 30 
variables must be used, define your own and initialize them 
with an &READ VARS control statement. 



805 MAX DEPTH OF LOOP NESTING EXCEEDED 

Up to four nested loops using the SLOOP control statement may 
be specified. If more than this are reguired, use another 
technigue for loop control for additional levels of nesting. 

806 DISK OR TERMINAL READ ERROR 

An error occurred while reading from a disk or user terminal. 
Try the EXEC procedure again. If the error persists, contact 
you computer center for assistance. 

807 INVALID SYNTAX 

The syntax of the indicated statement is incorrect. Correct 
the error and try the EXEC procedure again. 

808 INVALID FORM OF CONDITION 

The conditional expression in the indicated statement is 
invalid. This error can arise due to faulty logic, but when 
the logic is correct, it occurs most often when some reguired 
argument is not passed to the EXEC procedure. 

809 INVALID ASSIGNMENT 

The assignment in the indicated statement is invalid. The 
types of errors that can cause this message to appear are 
like those for INVALID FORM OF CONDITION (808) . 

810 MISUSE OF SPECIAL VARIABLE 

One of the special EXEC variables was improperly used in the 
indicated statement. Review the rules for use of the special 
EXEC variables and correct the error before attempting to use 
the EXEC procedure again. 
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Return 

£ode__ Message and Exglanation 
811 ~ ERROR IN &ERROR ACTION 

The action specified when the indicated &ERROR statement was 
executed resulted in a processing error. You should correct 
both errors before attempting to use the EXEC procedure 
again. 

312 CONVERSION ERROR 

An error occurred in the indicated statement when the EXEC 
interpreter attempted to convert one type of data to another. 
This can happen when you try to perform arithmetic operations 
on alphabetic d 
procedure again. 

813 TOO MANY TOKENS IN STATEMENT 

No more than 19 tokens can appear in a single EXEC statement. 
Reduce the number of tokens in the indicated statement and 
try the EXEC procedure again. 

814 MISUSE OF BUILT-IN FUNCTION 

One of the EXEC built-in functions was improperly used in the 
indicated statement. Review the rules for use of the 
built-in functions and correct the error before attempting to 
use the EXEC procedure again. 

815 EOF FOUND IN LOOP 

The end of the EXEC file was encountered at the indicated 
statement while execution was being controlled by an &LOOP 
control statement. Check for an incorrect limit value or a 
failure to attain an exit condition during loop execution. 
When the error is corrected, try the EXEC procedure again. 

816 INVALID CONTROL WORD 

The EXEC interpreter does not recognize a control word in the 
indicated statement. Locate and correct the error before 
using the EXEC procedure again. 

Note: None of the EXEC processing errors can be corrected dynamically. 
Depending on the error, you must either correct the indicated error and 
invoke the EXEC procedure again, or simply invoke the EXEC again with 
correct arguments. 



SPECIAL EXEC FILES 

Certain EXEC files have special uses in a CMS virtual machine. They 
are: 

• PROFILE EXEC, which allows a user to set up his own operating 
environment within CMS. 

• CMS EXEC, which is a file of 80-character records created by the CMS 
LISTFILE command. 

• EDIT macros, which are special EXEC files that contain only EXEC 
control words and EDIT subcommands. 
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Each of these special EXEC files is discussed in this section under a 
separate heading. 

PROFILE EXEC 

A PROFILE EXEC is an EXEC procedure that tailors a CMS virtual machine 
to the user's specifications. If you usually enter several commands to 
change your virtual machine after you load CMS, you should set up your 
own PROFILE EXEC to execute these commands for you. This will save you 
the trouble of entering these commands every time you IPL CMS. 

A PROFILE EXEC can be as simple or as complex as you reguire. It is 
a normal EXEC file, and thus it can contain any valid EXEC control 
statements or CMS commands. The only thing that makes it special is its 
filename, PROFILE, which causes it to be executed the first time you 
press the RETURN key after loading CMS. 

Usually, the first thing you do after loading CMS is to type a CMS 
command. When you press the RETURN key to enter this command, CMS 
searches your A-disk for a file with a filename of PROFILE and a 
filetype of EXEC. If such a file exists, it is executed before the 
first CMS command entered is executed. Because you do not do anything 
special to cause your PROFILE EXEC to execute, you can say that it 
executes "automatically. " 

Note: You can prevent your PROFILE EXEC from executing automatically by 
entering: 

ACCESS (NOPROF) 
as the first CMS command after you IPL CMS. You can enter: 

PROFILE 

at any time during a CMS session to execute the PROFILE EXEC. 

For example, if you want to set up a CMS virtual machine that 
redefines the blip characters and CMS Ready message, you could create 
the following PROFILE EXEC: 

SCONTROL OFF 

SET BLIP * 

SET RDYMSG SMSG 

In addition to establishing an operating environment, you could also 
perform such functions as linking to another minidisk, accessing it, and 
manipulating files that are found on it. An Assembler Language 
programmer may want to include a GLOBAL command in his PROFILE EXEC to 
ensure access to the CMS and OS macro libraries, while a PL/I user would 
want to have the PL/I Program Product libraries available. 

An example of a PROFILE EXEC to do some of these things is: 

SCONTROL OFF 

LINK PUBS 191 291 RR RDPAS 

ACCESS 291 B/A 

GLOBAL MACLIB CMSLIB OSMACRO 

SET BLIP Z 

SET RDYMSG SMSG 

Note: You can use SEXIT to specify a return code to be displayed when 
the PROFILE EXEC finishes processing. If the return code ycu specify in 
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this way depends on the value of 8RETC0DE, the return code is displayed 
only if you have executed the PROFILE EXEC by entering 

PROFILE 

If the PROFILE EXEC is executed automatically, however, the return code 
is not displayed. Only the normal CHS ready message (R;) is displayed, 
to show that CHS has executed the PROFILE EXEC. 

For example, suppose your PROFILE EXEC is: 

&CONTROL OFF 

SET RDIHSG SHSG 

GLOBAL TXTLI6 CDHLIB 

8IF SRETCODE HE &BXIT 1 

&EXIT 

If this PROFILE EXEC is executed automatically and CDHLIB cannot be 
found, the following message is issued: 

FILE 'CDHLIB TXTLIB' SOT FOUND. 

R; 
If the same EXEC is executed by your entering 

PROFILE 

the return code is displayed, as follows: 

FILE 'CDHLIB TXTLIB' HOT FOUND. 
R (00001) ; 

If the file is found, the normal CHS ready message is issued in either 
case. 



CHS EXEC 

A CHS EXEC file is a special file of 80-character records that is 
created on a user's primary disk by the CHS LISTFILE command. The 
format of each record in the file is: 

&1 &2 filename filetype filemode 

The variables S1 and 82 are standard EXEC numeric variables. The 
filename, filetype, and filemode are those specified in the LISTFILE 
command. (The LISTFILE command is described in the VH/370: Command 
Language Guide for General Users.) 

Judicious use of the LISTFILE command and CHS EXEC can save much 
repetitive work in certain situations. For example, if you have several 
files with a filetype of ASSEHBLE that you want punched so that they can 
be transferred to some other user, you can do this in two ways: 

1. You can enter the coimand: 

DISK DUHP filename ASSEHBLE 

for each file to be moved. If many files are involved, this can be 
a tedious, time-consuming procedure. 
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2. You can create a CHS EXEC file by entering the coenand: 

LISTFILE * ASSEMBLE * (EXEC) 

which creates a file named CHS EXEC with 80-character records in 
the foraat described previously. One record is created for each 
file found with a filetype of ASSEHBLE. You could then issue the 
command: 

CHS DISK DOHP 

When the CHS EXEC is executed, the argument DISK is assigned to SI, 
DUHP is assigned to S2, and a DISK DOHP command is thus created for 
each record in the file. 

If your virtual punch is spooled to the user to whom you want 
the files to go, each file is punched to that user. 

The CHS EXEC variables 51 and S2 can be assigned any arguments that 
create a valid CHS command or EXEC control statement. (No arguments 
need be specified at all, if desired). 

A more comprehensive example of the use of the LISTFILE command and 
CHS EXEC is found in the section entitled "An Annotated EXEC 
Procedure." 



EDIT HACROS 

If you have a good knowledge of the CHS EXEC facilities, you can write 
your own EDIT macros. You must ensure that any EDIT macro you write 
checks the vaTi'di'ty of its operands and displays an error message if 
necessary. 

The conventions followed when creating EDIT macros are: 

1. EXEC files that are EDIT macros have a filename that starts with a 
dollar sign ($) and a filetype of EXEC. These files are referred 
to as EDIT macro files. 

2. An EDIT macro subcommand consists of the name of an EDIT macro file 
(including the initial $) , possibly followed by operands. 

3. An EDIT macro file contains only EDIT subcommands and EXEC control 
statements. EDIT macros can execute only in EDIT mode. 

Operands of an EDIT macro must be separated from the macro name, and 
from each other, by at least one blank. Percent signs (%) cannot be 
entered as operands, since they have a special meaning to the EXEC 
interpreter. Operands passed to an EDIT macro are subject to the same 
rules as any other EXEC file (that is, the length of an operand must not 
exceed eight characters) . 

Bhen you create the macro, IHAGE mode must be off if you include tab 
characters (X'OS") . 

All EDIT subcommands in EDIT macros must be stacked (that is, you 
must specify SSTACK or SBEGSTACK before the EDIT subcommands) . If your 
EDIT macro uses variables, you should use SSTACK rather than SBEGSTACK, 
since SBEGSTACK inhibits substitution of variables. 

If an EDIT macro is issued, and the EDIT macro file does not exist, 
the Editor issues the message ?EDIT:. If an EDIT macro is used 
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incorrectly, the Editor displays a message, and the macro is ignored. 
If an EDIT macro is assigned to X or Y # it is an error to issue that X 
or Y subcommand with a numeric operand other than or 1. 

Some EDIT macros use the CHS DESBUF command during their execution 
(for example, $DDP and $MOVE) . If stacked lines exist when one of these 
macros is invoked, the macro deletes the stacked lines and issues the 
message STACKED LINES CLEARED BY (macro name) . This also occurs in 
user-written macros if the CBS line end character has been used to stack 
additional subcommands after the macro is issued. 

A user-written EDIT macro that uses first-in, first-out (FIFO) 
stacking should ensure that the stack is initially clear. You do this 
by including in your EDIT macro the line 

6IF SREADFLAG EQ STACK DESBUF 

before you stack anything. The EESBDF command clears the console 
stack. Alternatively- your EDIT macro can use last-in, first-out (LIFOj 
stacking to avoid having to initially clear the console stack. 

If the operation of an EDIT macro is completed without an error, the 
Editor clears any stacked lines and issues the message STACKED LINES 
CLEARED. Thus, the macro has no effect on the Editor or its contents. 

To avoid having the Editor type during execution of your EDIT macros, 
you can specify that your EDIT macros operate with verification off. 
You can accomplish this without losing your setting by stacking PRESERVE 
and VERIFY OFF for execution first, and RESTORE for execution last. 

Do not interrupt the execution of an EDIT macro by pressing the ATTN 
(attention) key or its eguivalent. 

An example of an EDIT macro that you could write is the following, 
which puts a continuation character in column 72 of an Assembler 
Language source statement. Remember to issue the EDIT subcommand IMAGE 
OFF before you create this EXEC, because it includes tab characters. 

SCONTROL OFF 

SBEGSTACK 

PRESERVE 

VERIFY OFF 

TRUNC * 

TABS 1 72 

SEND 

8STACK REPEAT S1 

&BEGSTACK 

OVERLAY C 

(Enter a blank and a tab character between OVERLAY and C.) 
RESTORE 
SEND 

If you name this file $CONT EXEC, then when you want to put a 
continuation character in column 72, you can: 

1. Enter the Assembler Language source statement (except for the 
continuation character) . 

2. Enter a null line to get into EDIT mode (from INPUT mode) . 

3. Invoke the $CONT EXEC to put a continuation character in column 
72. 

4. Enter INPUT mode and continue entering source statements. 
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Two EDIT macros are supplied with VM/370: $DOP and $BOVE. These are 
described in "Section 4. EDIT Macros" in the VM/370: EDIT Guide . 
"Appendix B. User-Written EDIT Macros" in the VM/370 : EDIT Guide 
describes other EDIT macros that you can create and lay find useful. 
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CONTROLLING THE CMS BATCH FACILITY 

The EXEC facilities provide you with a convenient way of controlling the 
CMS Batch Facility. Using EXEC procedures, you can simulate terminal 
control of your batch job execution, while freeing yourself of the 
repetitious tasks involved in preparing input for the batch card reader. 

Since the CMS Batch Facility executes commands in the same way as a 
normal CMS virtual machine, you can submit data to it in three primary 
ways : 

1. Invoke EXEC procedures in your virtual machine to punch the 
necessary commands to the batch card reader. 

2. Punch EXEC files to the batch card reader in such a way that the 
EXEC files are loaded on the batch machine's prin>.ar v disk, and are 
then executed in the batch machine. 

3. Punch appropriate commands to the batch card reader to cause the 
batch machine to link to a user disk and invoke an EXEC procedure 
that resides on that disk. 

Of course, any combination of these (or other) methods may serve the 
purpose of a particular user job. Methods 2 and 3 also show how to make 
a data file (such as a source file for an assembly) available to the 
batch machine. You can either punch the data file (preceded by 
appropriate CMS commands) directly to the batch reader, or punch a 
series of commands that enable the batch machine to link to a user disk 
and have access to the data file. 

To simulate actual console input, the batch machine truncates 
trailing blanks from every record it reads from its card reader and 
determines the length of the line read accordingly. Thus, a blank 
record is treated as a null line. 

The only exception to the normal batch machine handling of /* (end of 
job) and blank records is that of using /* as an end-of-file indicator 
when MOVEFILE is executing and reading from the console (batch card 
reader) . The /* is translated to a null line so that blank data records 
can be read in as data, and so that MOVEFILE can recognize an 
end-of-file from the console. This is the only time that the batch 
machine does not interpret /* as an end-of-job indicator, and the only 
condition when a blank record is treated as a blank card-image record 
rather than as a null line. 

This use of the MOVEFILE command is helpful with input method 2 
above, in which the data file may be preceded with two FILEDEF commands 
and a MOVEFILE command, and followed by a /* record. If the input data 
file is defined as residing at the console, MOVEFILE reads the data file 
from the console and recognizes the null line (the /* record translated 
by the CMS Batch Facility) as the end of the data file. 
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SAMPLE PROCEDURES FOR BATCH EXECUTION 

The sample EXEC procedures in this section can be used to assemble 

Assembler Language source files under control of the CMS Batch Facility. 

The three EXEC files are named BATCH EXEC, INPUT EXEC, and ASSEMBLE 
EXEC. 

1. BATCH EXEC 

* THIS EXEC SUBMITS ASSEMBLIES/COMPILATIONS TO CMS BATCH 
* 

* - PUNCH BATCH JOB CARD; 

* - CALL INPUT EXEC TO PUNCH DATA FILE; 

* •» CALL APPROPRIATE LANGUAGE EXEC (&3) TO PUNCH EXECUTABLE COMMANDS 

* 

&CONTROL ERROR 

SIF &INDEX GT 2 SSKIP 2 

&TYPE CORRECT FORM IS: BATCH USERID FNAME FTYPE (LANGUAGE) 

&EXIT 100 

SERROR &GOTO -ERR1 

CP SPOOL D CONT TO BATCHCMS 

&PUNCH /JOB &1 1111 S2 

EXEC INPUT &2 &3 

EXEC &3 &2 &1 

&PUNCH /* 

CP SPOOL D NOCONT 

CP CLOSE D 

CP SPOOL D OFF 

&EXIT 

-ERR1 SEXIT 100 

2. INPUT EXEC 

* CORRECT FORM IS: INPUT FNAME FTYPE 

* 

* PUNCH DATA FILE FOR BATCH PROCESSOR; THE /* LINE BEHIND THE 

* DATA FILE IS TRANSLATED TO A NULL LINE BY BATCH SO THAT MOVEFILE 

* RECOGNIZES THE END OF THE DATA SET. 
* 

&CONTROL ERROR 

&ERROR &GOTO -ERR3 

SPUNCH FILEDEF INMOVE TERM (BLOCK 80 LRECL 80 RECFM F 

&PUNCH FILEDEF OUTMOVE DISK 81 &2 (BLOCK 80 LRSCL 80 RECFM F 

&PUNCH MOVEFILE 

PUNCH S1 &2 * (NOHEADER) 

&PUNCH /* 

&EXIT 

-ERR3 &EXIT 103 

3. ASSEMBLE EXEC 

* CORRECT FORM IS: ASSEMBLE FNAME USERID 

* PUNCH COMMANDS TO: 

* - INVOKE CMS ASSEMBLER 

* - RETURN TEXT DECK TO CALLER 
* 

&CONTROL ERROR 

SERROR SGOTO -ERR2 

&PUNCH CP LINK &2 191 199 RR PASS= RPASS 

SBEGPUNCH 

ACCESS 199 B/B 

GLOBAL MACLIB UPLIB CMSLIB OSMACRO 

RELEASE 199 
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SEND 

SPUNCH CP MSG S2 ASMBLING »S1 « 

8PUNCH ASSEMBLE 81 (PRINT NOTERM) 

SPUNCH CP MSG 82 ASSEMBLY DONE 

SPUNCH CP SPOOL D TO 82 NOCONT 

SPUNCH PUNCH S1 TEXT A1 (NOHEADER) 

8BEGPUNCH 

CP CLOSE D 

CP SPOOL D OFF 

CP DETACH 199 

SEND 

SEXIT 

-ERR2 SEXIT 102 

These EXEC files use both methods of making data files available to 
the batch machine for job execution, that is, the user's macro library 
UPLIB is on his 191 disk. Instead of punching the file to the batch 
card reader and using MOVEFILE to write the file to the batch machine's 
disk (as he does with the source file) , the user enables the batch 
machine to link to his disk and gain access to the macro library needed 
for the assembly. 

Executing the Sample EXEC Procedure 

This section describes the seguence of events that occur when the sample 
job is submitted to the CMS Batch Facility. The BATCH EXEC is invoked, 
with arguments, as follows: 

Terminal Tygeout Source 

batch name payroll assemble User 

PUN FILE 0073 TO BATCHCMS CP 
R: CMS 

At this point, the BATCHCMS reader file contains the following 
statements (in the same general form as a FIFO console stack) : 

/JOB NAME 1111 PAYROLL 

FILEDEF INMOVE TERM (BLOCK 80 LRECL 80 RECFM F 

FILEDEF OUTMOVE DISK PAYROLL ASSEMBLE (BLOCK 80 LRECL 80 RECFM F 

MOVEFILE 



source file (PAYROLL ASSEMBLE) 



/* 

CP LINK NAME 191 199 RR PASS= RPASS 

ACCESS 199 B/B 

GLOBAL MACLIB UPLIB CMSLIB OSMACRO 

RELEASE 199 

CP MSG' NAME ASMBLING 'PAYROLL' 

ASSEMBLE PAYROLL (PRINT NOTERM) 

CP MSG NAME ASSEMBLY DONE 

CP SPOOL D TO NAME NOCONT 

PUNCH PAYROLL TEXT A1 (NOHEADER) 

CP CLOSE D 

CP SPOOL D OFF 

CP DETACH 199 

/* 
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Eventually, the following messages appear on the user console (if 
connected) : 

Message Source 

FROM~BATCHCMS: JOB 'PAYROLL' STARTED Batch"" 

FROM BATCHCMS: ASMBLING 'PAYROLL' User job 

FROM BATCHCMS: ASSEMBLY DONE. User job 

PUN FILE 0082 FROM BATCHCMS CP 

FROM BATCHCMS: JOB 'PAYROLL' ENDED Batch 

At this point, the user has the resultant object deck (PAYROLL TEXT) 
in his card reader. 

A Batch EXEC for a Non-CMS User 

If an installation is running the CMS Batch Facility for non-CMS users, 
a series of EXEC files could be stored on the system disk so that each 
user need only include a card to invoke the system EXEC, which in turn 
would execute the correct CMS commands to process his data. 

For example, if a non-CMS user wanted to compile FORTRAN source 
fil^s, the following BATFORT EXEC file could be stored on the system 
residence disk: 

SCONTROL OFF 

FILEDEF INMOVE TERM (RECFM F BLOCK 80 LRECL 80 

FILEDEF OUTMOVE DISK &1 FORTRAN A1 (RECFM F LRECL 80 BLOCK 80 

riOVFILE IN OUT 

GLOBAL TXTLIB FORTRAN 

FORTGI &1 (PRINT) 

&FORTRET = &RETCODE 

&IF &RETCODE NE SGOTO -EXIT 

PUNCH S1 TEXT A1 (NOHEADER) 

-EXIT &EXIT &FORTRET 

Using this EXEC, the non-CMS user could place a real card deck in the 
system card reader (the first job must have a CP userid card) . The 
statements to invoke the BATFORT EXEC would be as follows: 

/JOB JOEUSER 1234 JOB10 
BATFORT JOEFORT 



source file 



/* 

/* 



(end-of-file indicator) 
(end-of-job indicator) 



The BATFORT EXEC moves the source file onto the batch machine work 
disk with a file identification of JOEFORT FORTRAN. The FORTRAN G1 
compiler is then invoked, and if the return code is 0, the JOEFORT TEXT 
file is punched for JOEUSER. 

Additional functions may be added to this EXEC procedure, or others 
may be written and stored on the system disk to provide, for example, a 
compile, load, and execute facility. These EXEC procedures would allow 
an installation to accommodate the non-CMS users and maintain common 
user procedures. 
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AN ANNOTATED EXEC PROCEDURE 

The following EXEC procedure could be used to assemble all the ASSEMBLE 
files on a user's primary disk (A-disk) . The numbers to the left of 
each statement are not part of the EXEC file, but are simply reference 
points for the discussion that follows the EXEC procedure. 

1 &CONTR0L ERROR 

2 LISTFILE * ASSEMBLE A1 (EXEC) 

3 EXEC CMS &STACK 

4 GLOBAL MACLIB &2 CMSLIB 

5 &LOOP -LOOPEND &RSADFLAG EQ CONSOLE 

6 &READ ARGS 

7 ASSEMBLE &1 

8 &ASMRET = &BETCODE 

9 &IF &RETCODE GT 4 &SKIP 2 

10 PRINT &1 LISTING A1 
1 1 ERASE &1 LISTING A1 

12 -LOOPEND &C0NTINUE 

13 &EXIT &ASMRET 

The function of each of the statements in this sample EXEC procedure 
is as follows: 

1. The &CONTROL statement specifies that only those CMS commands that 
result in a nonzero return code are to be typed at the user's 
terminal. In addition, the return code is typed in the CMS ready 
message. 

2. The LISTFILE command creates a CMS EXEC file that contains the 
names of all the files on the user's A-disk that have a filetype of 
ASSEMBLE. For each ASSEMBLE file found, a record is created in the 
CMS EXEC file in the following format: 

&1 &2 filename ASSEMBLE A1 

3. The CMS EXEC is invoked with the argument &STACK. Thus, each 
record in the CMS EXEC file is placed in the terminal input buffer 
in the following format: 

filename ASSEMBLE A1 

4. The GLOBAL command locates and gains access to the macro libraries 
required for the assembly. The user can specify any library he 
wishes by passing an argument to the EXEC procedure in the second 
argument position. 

5. The loop that is created by &LOOP executes each statement down to, 
and including, the label -LOOPEND, until such time as the special 
variable &READFLAG has a value of CONSOLE. As long as there are 
records in the console stack (placed there by statement 3) , the 
loop continues to execute. 

6. The &READ statement reads a line from the console stack, assigning 
it tokens to the numeric variables &1, &2 , &3, etc. 

7. The ASSEMBLE command causes the file named in the variable &1 to be 
assembled. 

8. This statement saves the return code from the Assembler in the 
user-defined variable 5ASMRET. 
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9. The &IF statement checks to see if the return code from the 
Assembler is greater than four. If it is, the next two lines are 
skipped. If not, no skipping of lines occurs, and control passes 
to the next sequential statement. 

10. The PRINT command causes the LISTING file of assembled source 
statements to be spooled to the user's virtual printer. 

11. When the LISTING file has been spooled, it is erased to make room 
for the next one (if any) . 

12. This statement marks the end of the loop defined in statement 5. 

13. When the loop is through executing, &EXIT passes control back to 
CHS with the return code from the most recent assembly (contained 
in &ASMRET) , not from the most recently executed CMS command (which 
might be ERASE) . 

Many other combinations and variations are possible in the 
construction of EXEC procedures. The reader is encouraged to 
investigate the capabilities of the EXEC facilities in depth. The uses 
to which EXEC procedures can be put in your VM/370 system should be 
limited only by your imagination and any performance criteria that must 
be net. 
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APPENDIX A: EXEC CONTROL STATEMENT SUMMARY 



The charts in this section provide a quick reference summary of the EXEC 
control statements and built-in functions. Should you need more 
information than that in the charts, see the appropriate discussion in 
the body of this book. 



EXEC Command 




Description 


Control Statements and Built-in Functions 


EXEC 


EXec f n [args. . . ] 


Invokes EXEC files. 


The formats of the EXEC control statements 




and built-in functions are as follows: 


Defines or redefines 


SARGS [argl [arg2 . .. ]] 


arguments in the 




EXEC file. 




Punches the 


&BEGPUNCH [ALL] 


following lines of 




this EXEC file 




into cards. 






r t r t 


Stacks the following 


SBEGSTACK |FIFO| |ALL| 


lines of this EXEC 


JLIFOI «- J 


file into the 


L J 


terminal input 




buffer. 




Types the follow- 


&BEGTYPE [ALL] 


ing lines of this 




EXEC file at the 




terminal. 




Concatenates tokl 


8C0NCAT tokl {tok2 ...} 


and tok2 into a 




single token. 




Used in conjunction 


SCONTINUE 


with an EXEC label 




to provide an 




address for branch 




statements. 






r ir i r i r i 


Supplies the 


SCONTROL |OFF | |TIME | |PACK | |MSG | 


console printout 


|ERROR| |NOTIME| |NOPACK| |NOMSG| 


parameters for the 


|CMS | •- J «- J «- J 


execution phase of 


|ALL | 


the EXEC file. 


L J 


Allows the token 


&DATATYPE tok 


to be known from 




this point on by its 




composition (that 




is, numeric or 




character data) . 
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EXEC Command 
Description 



Control Statements and Built-in Functions 



Indicates the 
completion of the 
action started by 
SBEGPUNCH, &BEG- 
STACK, or &BEGTYPE. 

Provides an execu- 
tion path for a 
previous EXEC file 
statement that 
resulted in a non- 
zero return code. 

Exits from the 
EXEC file with a 
given return code. 

Transfers control 
to a defined 
location. 

Allows statement 
execution if the 
comparison is 
satisfied. 



Indicates the num- 
ber of nonblank 
characters in the 
following token. 

Allows the use of 
the literal value 
of the token with- 
out substitution. 

Repetitively exe- 
cutes a seguence 
of statements a 
defined number of 
times or until a 
specific condition 
is achieved. 

Punches a card 
with the defined 
tokens. 

Reads the next 
line (or lines) 
from the terminal 
and treats the 
data as part of 
the EXEC file. 



&END 



&ERROR action 



&EXIT | return-code | 
I | 



&GOTO 



TOP 

line— number 

label 



&IF (tokl 

&$ 
&* 



&LENGTH tok 



EQ 
NE 
LT 
LE 
GT 
GE 



tok2 ) executable 



&$ 
&* 



statement 



SLITERAL 



tok 



rLOOP i n ) \ m 

\ label / | condition 



&PUNCH tokl [tok2 ... ] 



&READ |n 

II 

| ARGS 

IVARS varl [var2 . 

L 



•] I 

J 
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EXEC Command 
Description 



Skips subsequent 
statements or 
transfers control 
up or down in the 
EXEC file. 

Types blank lines 
at the terminal. 



SuaCfcs a j-ine Oi 
tokens in the 
terminal input 
buffer. 

Extracts the 
desired string of 
characters from 
the given token. 

Types at the 
terminal time infor- 
mation pertaining 
to EXEC file 
execution. 

Types at the 
terminal a line 
containing the 
indicated tokens. 



Control Statements and Built-in Functions 



r i 

&SKIP ( n | 

L J 



r t 

&SPACEI n | 

I 1 I 

L J 



. n. v- i\ j i_.ii.ii i L 

|LIFO| 

L J 



&SUBSTR tok i [ j ] 



r i r t 

STIME |0N I |RESET| 

|OFF| |TYPE | 

L J L J 



&TYPE tokl [tok2 ... ] 
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Index 



S$ special token 23 

use of 42 
6* special token 23 

use of 42 
S character, use of in variable names 12 
SARGS control statement 17 

use of 33 
SBEGPUHCH control statement 18 

use of 11 
SBEGST1CK control statement 18 

use of 11,48 
SBEGTYPE control statement 19 

use of 11,38 
SCOHCAT built-in function 28 
SCOMTIHUE control statement 19 

use of 61 
SCONTROL control statement 19 

use of 61 
SDATATYPE built-in function 28 
SEHD control statement 20 

use of 38 
SBBBOR control statement 21 

use of 43,50 
SEXIT control statement 21 

use of 44,61 
SGLOBAL special variable 30 
SGLOBALn special variable 30 
SGOTO control statement 22 

use of 43 
SIF control statement 22 

use of 41,42,61 
SIHDEX special variable 31 

use of 34 
SLIHGTB built-in function 26 

use of 34 
SLINESUM special variable 31 
SLITERAL built-in function 29 

use of 46 
SLOOP control statement 

use of 45,61 
Sn special variable 30 

use of 61 
SPUBCB control statement 
SREAD control statement 

use of 33,36,61 
8RE1DFLAG special variable 31 

use of 49,56.1,61 
SRETCODE special variable 31 

use of 22,50,61 
SSKIP control statement 25 

use of 44 
6SPACE control statement 25 
SSTACK control statement 26 

use of 47;61 
SSOBSTR built-in function 29 

use of 46 
STIME control statement 26 
&TYPE control statement 27 

use of 37 
STYPEFLAG special variable 31 

use of 40 



23 



24 
24 



$D0P EDIT macro 56.1,56.2 
SHOVE BDIT macro 56.1,56.2 



% sign, use of 10,56 



= sign, use of 13 



adjusting counters 45 

ampersand (S) , use of in variable names 12 

analysis, of EXEC statements 15 

annotated EXEC procedure 61 

arguments 

checking for number of 34 

checking for specific 35 

checking length of 34 

determining number of 31 

in EXEC command 10 

passing to an EXEC procedure 33 

reading from a terminal 24,36 
ASSEMBLE command 61 
assigning a value to a counter 45 
assigning values to symbolic variables 10 
assignment statements 13 
avoiding substitution in a token 29 



B 

Batch Facility 
CaS 

controlling with EXEC procedures 57 
executing the sample EXEC procedure 

59 
for non-CBS users 60 
saiple EXEC procedures for 58 
blank lines, typing 25 
blank tokens, handling of 15 
branch statements 
SGOTO 22 



8SKIP 25 




use of 43 




branching 




with SGOTO 


22,43 


with SSKIP 


25,44 


building EXEC 


procedures 


built-in functions 


EXEC 




SCOHCAT 


28 


SDATATYPE 28 


SLEBGTE 


28 


SLITEBAL 


29 


SS0BSTB 


29 



33 
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cataloged procedures, OS 7 
checking 

for a specific argument 35 

for CHS error return codes 50 

for execution errors 49 

for length of an argument 34 

for number of arguments 34 
CHS 

Batch Facility, controlling 57 

Editor 8 

error return codes, checking for 50 

execution, controlling 47 

files, typing at a terminal 39 
CHS commands 

as EXEC statements 12 

ASSEHBLE 61 

CP 12 

DISK 55 

EDIT 8 

EXEC 7,10 

executing 7 

GLOEAL 61 

LISTFILE 8,61 

PRIST 9,61 

TYPE 9,39 
CHS EXEC 

described 55 

example of 55 
code 

return 

examining 31 
specifying 21 
command line, length of 11 
commands 

as EXEC statements 12 

ASSEHBLE 61 

CHS, executing 7 

CP 12 

DESBOP 56.1 

DISK 55 

EDIT 8 

EXEC 7, 10 

GLOBAL 61 

invoking from an EXEC procedure 12 

LISTFILE 8,61 

longer than 72 characters 11 

placing in a console stack 47 

PRINT 9,61 

reading from a terminal 24 

TERHINAL 26 

TYPE 9,39 
communicating with a terminal 35 
comparison operations 

examples of 42 

specifying 23 
concatenating a string of tokens 28 
conditional execution 

control of 22 

with &IF statement 41 

with &LOOP statement 45 
console output flag 31 
console stack 

clearing 56.1 

placing lines in 18 
example of 48 

placing tokens in 26 
example of 47 

using to control CHS execution 47 



control 

logical, setting up 40 
of conditional execution 22 
of EXEC processing loops 23 
of message typing 19 
passing via SGOTO 22,43 
passing via SSKIP 25 
control program (see CP) 
control statements 
EXEC 17 

SARGS 17 
&BEGP0HCH 18 
&BEGSTACK 18 
SBBGTYPE 19 
&C0NTINUE 19 
&CONTROL 19 
SEND 20 
&EBROR 21 
6EXIT 21 
SGOTO 22 
&IF 22 
SLOOP 23 
&PUNCH 24 
&READ 24 
&SKIP 25 
SSPACE 25 
&STACK 26 
STIHE 26 
&TYPE 27 

built-in functions 27 
execution control 17 
skipping 25 
special variables 30 
summary of 63 
in EXEC procedures 14 
control word, defined 14 
controlling execution "-of chs commands 47 
controlling the CHS Batch Facility 57 
Conversational Honitor System (see CHS) 
counters, defining and using 44 
CP command 12 
CP commands 

invoking from an EXEC procedure 12 
TERHINAL 26 



D 
data 

placing in a console stack 18 

punching 18,24 

reading from a terminal 24,36 

typing at a terminal 19,37 
data length, determining 28 
data type, determining 28 
defining variables 32 
DESBOF command 56.1 
DISK command 55 



EDIT command 8 
EDIT macros 

$DUP 56.1,56.2 

$H0VE 56.1,56.2 

described 56 

example of 56.1 
Editor, CHS 8 
ending EXEC processing 21 
equal sign (=) , use of 13 
error handling routines, identifying 50 
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error messages, EXEC processing 51 
error return codes, checking for 50 
errors 

CHS command processing 
default action 19 
handling 21 

execution, checking 49 
examining the output flag 40 
examining the read status flag 49 
example of an EDIT macro 56.1 
example of an EXEC procedure 61 
EXEC built-in functions 27 

SCONCAT 28 

SDATATYPE 28 

SLENGTH 28 

SLITERAL 29 

SSUESTR 29 
EXEC command 10 
EXEC control statements 17 

SARGS 17 

SBEGPUNCH 18 

SBEGSTACK 18 

&BEGTYPE 19 

&C0HTINUE 19 

&CONTROL 19 

SEND 20 

SERBOR 21 

&EXIT 21 

SGOTO 22 

SIF 22 

SLOOP 23 

&PUHCH 24 

&READ 24 

SSKIP 25 

SSPACE 25 

SSTACK 26 

&TIME 26 

STIPE 27 

summary of 63 
EXEC facilities, using 10 
EXEC files 

described 11 

format of 7 

number of lines in 11 

record lenght of 11 

special types 53 

writing 8 
EXEC interpreter 

function of 14 

processing 7 
EXEC procedure 

annotated 61 

building 33 

creating 7 

for a non-CMS user 60 

invoking 7 

labels in 40 

passing arguments to 33 

writing 8 
EXEC statements 

described 11 

summary of 63 
EXEC variables 

defined 12 

special 

SGLOBAL 30 
SGLOBALn 30 
SIHDEX 31 
SLIHENOM 31 
Sn 30 



&READFLAG 31 
SRETCODE 31 
&TYPEFLAG 31 
executable statements 11 
execution 

conditional 

control of 22 
with SIF statement 41 
with SLOOP statement 45 
controlling via console stack 47 
of an EXEC procedure 7 
execution control statements 17 
execution errors, checking for 49 
execution paths, defining 42 
exit, from an EXEC procedure 21 
extracting a substring 29 



fuenane, in EXEC command 10 
files 

CMS, typing at a terminal 39 
EXEC 

defined 11 
format of 7 
number of lines in 11 
record length of 11 
special 53 
writing 8 
flag 

output status 31 

checking 40 
read status 31 
checking 49 
format, of EXEC files 7 
functions, EXEC built-in 27 



GLOBAL command 61 

global variables, using 30 



identifying error handling routines 50 
IMAGE subcommand 56 
interpreter, EXEC, function of 14 
invoking an EXEC procedure 7 



L 
labels 

examples of use 41 

for EXEC statements 12 

in an EXEC procedure 40 

syntax and use 40 
leading zeros, removal of 13 
length of arguments, checking 34 
length of data, determining 28 
length of record, changing default 11 
line number, determining 31 
lines 

blank, typing 25 

typing at a terminal 38 
LISTFILE command 8,61 
lists, argument, in EXEC command 10 
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logic control 

in an EXEC procedure 40 

passing of 22,25 

setting up 40 
loop control 23 

with SLOOP 45 

with counters 44 
LRECL option 11 



macros, EDIT, described 56 
messages 

control of typing 19 

error, from EXEC processing 52 



nonexecutable statements 11 
null statements 12 
number of arguments 

checking 34 

determining 31 
numeric variables 

assigning values to 10 

defined 30 



operators, comparison, specifying 23 
OS, cataloged procedures 7 
output status flag 31 
checking 40 



parameters, reading from a terminal 24 
passing arguments to an EXEC procedure 33 
passing control 

with 8G0T0 43 

with SSKIP 44 
paths, defining 42 
percent sign (%) , use of 10,56 
period (.) , use of 46 

placing a command in the console stack 47 
placing several lines in the console stack 

48 
PRINT command 9,61 

procedure, EXEC (see EXEC procedure) 
processing 

control of 22 

errors 

default action 19 

EXEC 51 

specifying handling of 21 

messages, default action 19 
PROFILE EXEC 

described 54 

example of 54 
punching data 18,24 



reading data from a terminal 24,36 
recognizing EXEC processing errors 51 
record length, changing default 11 
removal of leading zeros 13 
repetitious statements, control of 23 
return codes 

CMS, checking for 50 

determining 31 

EXEC processing 51,52 

specifying 21 
routines, for error handling 50 



sample EXEC procedure 

annotated 61 

for CMS Batch Pacility 58 
executing 59 
scanning, of tokens 14 
seguence, of EXEC interpretation 14 
setting counters 45 

simulation, of subscripted variables 15 
skipping lines in an EXEC file 25 
spaces, inserting between lines 25 
special EXEC files 53 

CMS EXEC 55 

EDIT macros 56 

PROFILE EXEC 54 
special tokens (8$ and &*) 

defined 23 

null 42 

use of 42 
special variables 12.1,30 
specific arguments, checking for 35 
stack, console, using to control CMS 

execution ^ 
stacking, LIFO 50,56.1 

stacking EDIT subcommands in EDIT macros 

56 

stacking lines in the console stack 18,26 

statements 

EXEC control 17 

executable 11 
assignment 13 
CMS commands 12 
control 14 
null 12 

nonexecutable 11 
status flag 

output 31 

read 31 
stopping EXEC processing 21 
subscripting variables, simulation of 15 
substitution 

avoiding 29 

of EXEC variables 15 
substring, taking a 29 
summary, of EXEC control statements 63 
suppressed typing, avoiding 40 
symbolic variables 

assigning values to 10 

defining 30 
synttx, of EXEC labels 40 
syntax analysis, procedure 15 



read status flag 31 
checking 49 



tab characters 56 
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terminal 

communication with 35 

reading data from 36 

timing information typed at 26 

typing CHS files at 39 

typing data at 37 
TBRMIH1L command 26 

terminal input buffer (see console stack) 
testing counters 45 
tests, conditional 42 

timing information, typed at terminal 26 
token, defined 14 
tokens 

blank 15 

concatenating 28 

creation of 14 

placing in a console stack 26,47 

punching 24 

special (8$ and 8*) 23 

typing at a terminal 27,37 
transf erring contrcj. 22,25 
TYPE command 9,39 
type of data, determining 28 
typeout flag, checking 40 
typing 

data 19,27,37 

messages, control of 19 

of blank lines 25 

records from a CHS file 37 

suppressed 40 

timing information 26 

tokens 27 

variable data 38 
typing a CHS file 39 
typing a single line of tokens 37 
typing data at a terminal 37 
typing more than one line of data 38 



user-defined variables 32 

use of 22,61 
using counters for loop control 44 
using the CHS EXEC facilities 10 



variables 

numeric 30 

reading from a terminal 24,36 

special EXEC 30 

& GLOBAL 30 

SGLOBILn 30 

&IHDEX 31 

&LIHEH0H 31 

8n 30 

&HE1DFLAG 31 

&TIPEFLIG 31 

numeric 30 
subscripted, simulating 15 
substitution for 15 
typing contents of 37 
used in EXEC statements 12 
user-defined 32 



word, control, defined 14 
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